Subject: KampalaMeetingLog-2017-04-06.txt Date: April 7, 2017 at 9:29:56 AM PDT [15:01:40] good morning HideyoImazu-san, good evening HaraldJoerg! [15:01:42] Good morning, Harald! [15:01:48] Good afternoon, Peter [15:01:59] what's new? [15:02:00] Good afternoon, Peter [15:02:44] cherry blossom in full bloom in Tokyo [15:03:31] Nice. Didn't start here [15:04:01] it's one week or so earlier than 30 years ago [15:04:41] oh, global warming! [15:05:06] cherry blossom is already over here, best two weeks ago [15:05:37] i got a new toy two days ago, shipped from japan [15:05:50] what toy? [15:05:59] a f/0.95 lens, about the fastest you can go [15:06:13] 0.95! [15:06:18] 3x more sensitive than human eyes [15:06:35] best part: it's 55 years old [15:06:54] vintage canon called "dream lens" [15:07:02] using it with your digital camera with an adaptor? [15:07:07] yes [15:07:29] very heavy at 700g, 2x my camera [15:08:30] it's around 700 USD to 1k [15:08:31] test shot at https://www.flickr.com/photos/peterthoeny/33809236526/ [15:08:59] what's new in germany? [15:09:14] Not too much I'm afraid [15:09:44] I'm playing around with perlbrew [15:10:23] ok [15:10:28] shall we start? [15:10:39] sure [15:10:57] http://twiki.org/cgi-bin/view/Codev/KampalaReleaseMeeting2017x04x06 [15:11:09] 1. Feature Requests for Kampala Release [15:11:09] 2. Extensions [15:11:09] 3. Review Urgent and Not So Urgent Bugs [15:11:09] 4. TWiki Release Discussion [15:11:09] 5. Miscellaneous [15:11:27] ---++ 1. Feature Requests for Kampala Release [15:11:44] http://twiki.org/cgi-bin/view/Codev/WebChanges [15:12:27] first: [15:12:32] http://twiki.org/cgi-bin/view/Codev/TWikiWithCurrentPerl - by HaraldJoerg [15:13:09] That's one of the effect of my movement to Debian Stretch [15:13:30] Perl 5.24 introduces a bunch of new warnings, and several old warnings are now fatal [15:13:47] good progress on that front, thank you harald! [15:14:11] I can commit the changes to the bin stuff [15:14:15] looks like some more code cleanup needs to be done [15:14:23] yes, please do [15:14:49] in my environment, 5.20 is the latest. [15:14:53] Unit tests and plugins need more care, and time [15:15:17] what if we hijack all cgi and sessions related libs? [15:15:21] I wonder how big is the diff b/w 5.20 and 5.24 in terms of picky-ness [15:15:47] e.g. ship with those and make sure it gets loaded before anything else [15:15:48] Hideyo-san: About 200 locations in plugins :) [15:16:35] Peter: Difficult to can't make sure that it gets loaded before anything else if you need setlib to define the libraries first [15:18:00] not possible to change setlib and to require LocalLib set before running configure? [15:18:15] The most frequent warning in 5.24 is { in regular expressions, which needs to be written as \{ [15:18:50] Yes, one can run setlib "some lines earlier" [15:18:51] in regards to plugin, we initially only need to address the core plugins [15:19:02] all others can be fixed as needs arise [15:19:42] Correct. I didn't count, but more than 100 are affected [15:20:01] And a few don't compile at all, I'm doing these first [15:21:45] we have, what, about 25 core extensions? [15:21:59] i can help in those too [15:22:22] what needs to be fixed besides \{ in regex? [15:23:07] I can only check one by one... the unit test suite throws about 5000 lines of output [15:23:58] wow [15:24:01] I've done the \{ stuff, the question is whether I should commit it all at once or one commit per plugin [15:24:13] The unit tests need a lot of care [15:24:35] i recommend one bug item for perl fix, and to commit extension by extension [15:24:53] Ok [15:25:11] i can help out on doc update (rev history) [15:25:27] Ah, doc update... I totally forgot about that [15:25:51] And, BTW, having \{ fixed doesn't mean that a plugin will actually work [15:26:27] Maybe doc update can be done by scripting as well? [15:26:39] yes, but it won't break it either :-) [15:27:14] possibly, but i am pretty fast with doc updates [15:27:37] I can start committing stuff this weekend [15:27:41] i use a small fix meta script to fix the topic meta data to TWikiContributor [15:28:13] thanks, yes, a single bug item should be sufficient for all extensions [15:28:23] maybe better another bug item for core [15:28:32] so two bug items [15:28:38] what do you think? [15:28:40] Ok, I can do that [15:28:46] ok [15:29:12] i just looked at the diff you posted on proposal topic [15:29:18] New bug items for new types if incompabilities if I find some [15:29:31] so that forces carp to load from twiki first [15:30:06] not sure how much I can contribute, but I'm upgrading from Perl 5.10 to 5.20. So I may find and fix some incompatibilities [15:30:16] Yes, that's another bug item [15:30:55] this bug item is "under investigation" [15:30:59] lets get a handle [15:30:59] You'll encounter a couple of warnings which we ignore since Perl 5.12 :) [15:31:15] +1 - no brainer to accept :-) [15:31:25] +1 [15:32:05] HaraldJoerg? [15:32:08] Ok, thanks... so Kampala will be fit for Debian Stretch [15:32:12] obvious but... [15:32:14] +1 from me, of course [15:32:20] accepted by KampalaReleaseMeeting2017x04x06 [15:33:17] http://twiki.org/cgi-bin/view/Codev/ContextIsAdmin - by Vicki [15:33:29] no commit date and developer [15:34:29] it is relatively easy to implement [15:35:04] but I wonder how useful it is [15:35:04] yes [15:35:45] it's basically just a shortcut for a Set ISADMIN = %IF{...}% [15:35:58] what can be done in twiki prefs [15:36:35] i find it also a lower prio [15:36:50] we can leave the proposal as is until someone commits to it [15:36:57] what do you think? [15:37:07] The same [15:37:43] sounds reasonable [15:37:45] http://twiki.org/cgi-bin/view/Codev/WebAdminTopic - by Vicki [15:37:54] also no commit date and developer [15:38:28] i think this topic is worth a discussion [15:38:37] parenting all topics is a good idea [15:38:55] but i think it is better not to collude admin and user related stuff [15:40:04] how about introducing a mechanism to list all topics w/o parent? [15:40:13] for example, the WebChanges topic is a user topic, whereas the WebPreferences topic is an admin topic [15:40:48] More frequently I've been missing an easy way to exclude those "non-content" topics like Web* (but not WebHome) and *Form/*Template from searches [15:41:31] in my twiki installations i usually create a WebMaintenance topic that lists all admin and app topics [15:42:02] That's basically the same idea [15:42:22] HaraldJoerg: good point, i wish for that too [15:42:42] On a web, I have SCAFFOLDING variable having a comma separated list of non-content topics [15:43:14] HideyoImazu: Good idea, I like that! [15:43:29] in some installations i create app topics with form for all user generated content in a web, which makes it easy to separate out admin and user content [15:44:33] HideyoImazu-san: good idea, so you can use that in an excludetopic="" [15:45:35] back to vicki's idea [15:46:11] so, what about adding a WebMaintenance topic to all webs, parent admin topics to it [15:46:33] and in addition, parent all user related Web* topics to WebHome? [15:46:45] that requires changes to existing webs [15:46:48] I don't object but fail to see how to easily make use of it [15:47:19] i think vicki's idea is to use the tree plugin to list all topics nicely arranged [15:47:40] as I said earlier, how about introducing a virtual topic whose children are topics w/o parent? [15:48:03] (i introduced her to one of my clients as a content guru, and she is happily hacking away) [15:49:37] HideyoImazu-san: so that would be part of the tree plugin? or new variable in twiki core that creates a bullet list of all non-parented topics? [15:49:51] or new plugin that does the same? [15:50:01] i like the idea [15:50:08] Are these topics without parent? I thought WebHome is, sort of, a parent topic for all topics which don't have one explicitly set [15:50:46] yes, i see that too, if a topic has no parent, logically it belongs to WebHome [15:51:01] Just creating a list of unparented topics should be easy with query search [15:51:44] true, e.g. simply a matter of creating a new pref setting to hide that search [15:52:30] my idea is to enhance the child finding logic so that it behaves as if topics w/o parent are children of a virtual topic, e.g. "Gaia” or something [15:52:55] Ah, I see... so use a topic which doesn't actually exist [15:53:11] correct [15:53:15] call it NOPARENTTOPICLIST or the like [15:53:53] For me, having no parent topic does not carry any semantics [15:53:56] a topic named "Gaia" may exist. so the name needs to be the one really unlikely to be used [15:54:17] You can use a name which is illegal to use [15:54:28] sOMEthing_vERY_eSoTeric [15:55:00] $ROOT [15:55:42] ok, please add your feedback to this topics if you like [15:55:51] Ok [15:55:53] we let it stand until there is a committed developer [15:55:53] sure. I will [15:56:14] this is all for features [15:56:27] i have something misc we have to discuss today [15:56:36] and it is +56 min [15:56:43] i have a meeting coming up [15:57:07] shall we skip bugs and other items and go right away to misc? [15:57:20] I am glad that I don't have a meeting coming up after this one :) [15:57:33] yup, would be very late for you [15:57:40] We can skip bugs... many of them are feature requests anyway [15:57:42] i'm going to work [15:57:47] ---++ 5. Miscellaneous [15:58:01] HideyoImazu-san can you wait for a few min? [15:58:13] ok, here we go: [15:58:39] twiki.org has two servers: 1. twiki.org and 2. develop.twiki.org [15:58:42] I can wait [15:59:08] i pay for twiki.org, and get about 1/3 back through donations (i am fine with this) [16:00:25] the develop server hosting is donated by datapipe, which acquired another company that donated hosting, which in turn acquired another company that donated hosting [16:00:30] you get the picture [16:00:52] now datapipe is suddenly sending me collection notes of outstanding bills [16:01:03] of near $1000 [16:01:18] something fell through the cracks on their accounting side [16:01:59] anyway, i am handling this and sent all my docs that prove that datapipe committed to supporting the open source twiki project [16:02:13] i am waiting for their reply [16:02:31] in any case i am grateful for their support all these years [16:02:37] understood. I feel your pain. [16:02:45] at thispoint it is not clear if they will continue or not [16:03:01] if not, what shall we do? [16:03:15] i likely can get them to cancel the charges [16:04:03] but in case they do not offer to continue free hosting, should we look for a new free sponsor, or should we host develop on twiki.org? [16:04:17] what is your thought? [16:05:14] twiki.org has sometimes a high load due to spiders, and regularly in the evening my time during backup [16:05:26] I'm not familiar with the operations, but if I am not mistaken, then twiki.org is running on "stable" while develop is on "testing"? [16:05:35] i think it could handle develop load, but it might get somewhat slower [16:06:07] yes, the idea would be to create a new virtual domain on twiki.org, so separate installation from stable [16:06:24] in effect exactly the same setup like now, just in a virtual domain [16:06:24] Ah, ok [16:06:41] we do not need to decide now [16:06:44] HideyoImazu_ (ddfc2e55@gateway/web/freenode/ip.221.252.46.85) joined the channel [16:06:51] I lost connection [16:06:53] just give it some thought [16:07:12] and watch for a potential new sponsor in case the need arises [16:07:13] HideyoImazu (ddfc2e55@gateway/web/freenode/ip.221.252.46.85) left IRC (Ping timeout: 260 seconds) [16:07:23] if twiki.org can handle the load, using it for develop is an option [16:07:37] what was the last you saw before you lost connection? [16:07:58] i gotta run actually [16:08:06] my boss is waiting [16:08:13] what is your thought? [16:08:18] ttyl [16:08:22] ttyl [16:08:28] ttyl! [16:08:32] HideyoImazu_ -san please read the logs when i post them [16:12:45] HideyoImazu_ (ddfc2e55@gateway/web/freenode/ip.221.252.46.85) left IRC (Quit: Page closed) [16:12:56] HaraldJoerg (~haj@ip5f5bf8c5.dynamic.kabel-deutschland.de) left the channel