Release Meeting: 07 Mar 2016

 

(07:55:33 AM) gac410: Hi all!
(08:03:28 AM) andreli entered the room.
(08:04:11 AM) andreli: Hello
(08:04:23 AM) gac410: hi Andreli
(08:05:15 AM) gac410: hi everyone ...  Everyone in the right timezone?  Ready to begin?    agenda https://foswiki.org/Development/ReleaseMeeting02X02_20160307
(08:09:49 AM) JulianLevens entered the room.
(08:14:07 AM) JulianLevens: Hi
(08:14:44 AM) gac410: Hi JulianLevens ...  Quiet so far.    Hey all ... ready to begin?  Everyone awake?
(08:15:30 AM) gac410: ---++  Urgent task Review ...
(08:17:11 AM) gac410: One new one in the couple of weeks.  http://foswiki.org/Tasks/Item14004
(08:18:27 AM) gac410: EditRowPlugin  textArea cells don't preserve their Cols=  when editing an entire row.    I've looked at it and suspect it's maybe in css or js?   The generated HTML has the attribute but it seems to be ignored.
(08:18:33 AM) vrurg: Hi 
(08:19:03 AM) gac410: hi Vadim
(08:19:15 AM) CDot  entered the room.
(08:19:23 AM) jast: did you look using 'view source' or your browser's DOM inspector? (the latter shows the current state of the document, including changes made by javascript)
(08:19:49 AM) gac410: view source, jast
(08:20:10 AM) gac410: and "net trace"  since the edit box is supplied via ajax
(08:20:34 AM) gac410: TBH I don't exactly consider it urgent, but Lavr escalated it.  
(08:20:36 AM) jast: do we happen to have an example of the problem somewhere?
(08:20:58 AM) gac410: In the task itself
(08:21:20 AM) jast: oh, didn't see the button because I was not logged in. my bad.
(08:21:22 AM) gac410: Edit a single cell clicking the stain,  it gets the right size,   edit the row or table, and they are all the same size.
(08:22:14 AM) gac410: The original example used 10, 100 & 1000 for the 3 sizes,  but someone changed it to 10, 20, 50  which makes it less obvious.  But it's still broken
(08:22:25 AM) jast: oh, I believe it's incorrect HTML actually
(08:22:32 AM) jast: IIRC the attribute is called 'cols' and not 'columns'
(08:23:14 AM) jast: yeah, that's it
(08:23:24 AM) jast: straightforward to fix, then
(08:24:40 AM) gac410: damn   I didn't see that.
(08:26:57 AM) gac410: Thanks jast ... 
(08:27:15 AM) gac410: Any other tasks to discuss.   The rest on the blocking list are older.  
(08:27:20 AM) jast: fix landing in a few minutes
(08:27:32 AM) gac410: Ah   great  thanks
(08:29:55 AM) gac410: https://foswiki.org/Tasks/Item13966   might need some discussion as well.  The bug was *triggered* because comment plugin no longer uses CGI::<>  functions to generate html
(08:30:27 AM) gac410: So <!-- -->  comments seen in values inside tags break the rendering engine.
(08:30:48 AM) gac410: It's a very old smell that exists because of the way we parse html using regexes.
(08:32:06 AM) jast: should I mark 14004 as released in 2.1.1?
(08:32:13 AM) gac410: yes please
(08:34:22 AM) gac410: Regarding Item13966,  I think the fix is really in CommentPluin,  it should encode embedded < >  when generating html,  similar to CGI:..  functions.  rather than trigger a rewrite of our TML rendering engine
(08:34:41 AM) jast: certainly makes things easier, though technically <> characters in HTML attributes are perfectly valid
(08:35:24 AM) jast: I reviewed the spec after reading that item, and I learned things about HTML that I never wanted to know
(08:37:17 AM) jast: 14004 should now be fixed btw
(08:37:47 AM) gac410: It's fine to be technically correct.    But I suspect it's a complex,  significant change to our renderinng engine to accommodate a change in html generation that has a very simple solution
(08:38:01 AM) gac410: The triggering bug is http://foswiki.org/Tasks/Item13964
(08:38:02 AM) jast: absolutely
(08:38:17 AM) jast: I'm with you on this
(08:39:32 AM) gac410: CDot ... You did seem to object to fixing CommentPlugin HTML generation to encode the < >.   Is there a good reason to push this onto core.
(08:42:21 AM) gac410: Okay,  moving on ...   The rest of the "urgent" tasks just need dev's to work on them. 
(08:43:24 AM) vrurg left the room (quit: Quit: vrurg).
(08:44:02 AM) gac410: Feature proposals.   Taking them out of order.   ...  http://foswiki.org/Development/AddFormatControlToSearchChanges    No feedback yet.   
(08:44:29 AM) gac410: It's a fairly minor proposal.  Adds  some formatting information to $changes   similar to $summary in search.
(08:45:14 AM) gac410: Also http://foswiki.org/Development/AddPasswordManagementFunctions ...  Adds fields to the .htpasswd file.   Somewhat similar to what twiki has done.  
(08:45:48 AM) gac410: They are approaching their 14 days,  so speak soon .... or accept what results   :D
(08:46:43 AM) gac410: Nothing there I need to discuss,  just pointing them out.   The rest of the proposals are related to  Vadim's  Mooification
(08:47:26 AM) vrurg  entered the room.
(08:47:32 AM) gac410: http://foswiki.org/Development/CleanUpFoswikiLocales     proposes to change from Locales   to Unicode::Collate Locale
(08:48:00 AM) jast: I'd like to reiterate that collations aren't the only feature related to locales
(08:48:29 AM) JulianLevens: The other feature we use is LC_TYPE
(08:48:50 AM) gac410: corelist Unicode::Collate::Locale
(08:49:11 AM) gac410: and  no foswikibot.     It's 5.13.4
(08:51:50 AM) ***gac410 doesn't pretend to really understand all this.  so leaves it to experts to figure out :)
(08:52:01 AM) vrurg: locale pragma is evil. Whichever way it's replaced – I support it. Example: multidomain hosting with shared codebase where two sites want different locales.
(08:52:28 AM) JulianLevens: Does LC_TYPE still need to be supported?
(08:52:37 AM) jast: LC_CTYPE, I'm guessing?
(08:52:57 AM) jast: well, isn't it kind of the point of locales to get language-specific treatment of strings?
(08:53:30 AM) jast: in addition to CTYPE, what about case folding? what about date and number formats? etc.
(08:53:32 AM) JulianLevens: true, but could LC_TYPE be handled another way?
(08:53:57 AM) JulianLevens: It's global in nature at the moment
(08:54:22 AM) JulianLevens: sorry, LC_CTYPE
(08:54:23 AM) jast: maybe. I don't know. all I'm saying is that simply dropping locales with no replacement for most of its properties is maybe not the best way to go about it
(08:54:52 AM) JulianLevens: We have already dropped LC_COLLATE effectively
(08:54:52 AM) jast: if we do find ways to get all things locale without actually using POSIX locale support, great, I'm all for it
(08:55:21 AM) JulianLevens: Do we know of sites using locales?
(08:55:40 AM) vrurg: JulianLevens: I would use it if it's properly implemented.
(08:56:17 AM) ***vrurg would be happy to have LC_ALL
(08:57:10 AM) JulianLevens: Note that my proposal is not strictly about dropping locales par se. If we keep the existing LC_CTYPE support then I'd like to replace the BEGIN blocks with 'use Foswiki::Locale;'
(08:57:47 AM) JulianLevens: That just helps to separate concerns in that Foswiki::Locale has no dependencies of other parts of FW
(08:58:30 AM) ***gac410 implemented the change to sorting that broke LC_COLLATE    but would be happy to revert back if Locales were working / supported / usable.
(08:59:01 AM) jast: I'm a bit surprised that the approach with the separate module works... when I looked into this I found that 'use locale' is a scoped pragma
(08:59:46 AM) JulianLevens: You need some extra magic to make that work
(09:00:00 AM) JulianLevens: That's why I needed extra modules
(09:00:51 AM) jast: oh, I see... I kind of skimmed over that bit when reading
(09:00:54 AM) gac410: Does your solution JulianLevens  resolve the LC_CTYPE  and LC_COLLATE if we reverted the NFKD change from the sort 
(09:01:01 AM) jast: that's convenient
(09:01:35 AM) JulianLevens: It keeps the LC_CTYPE in place as is (working or broken :P )
(09:02:26 AM) JulianLevens: LC_COLLATE needs Unicode::Collate::Locale etc, but I can include that at least for replacing existing NFKD code
(09:02:51 AM) JulianLevens: I'm not guaranteeing to find all sorts that need sorting IYSWIM
(09:02:54 AM) gac410: So the one downside is that we need to have Perl 5.14
(09:03:51 AM) gac410: Have we reached the point of finally dropping 5.8 / 5.10 / 5.12  support for the next major release?     Or Minor release?  
(09:04:56 AM) gac410: Right now master branch is foswiki 2.2. and 3.0 ... so if it's a change that we don't want into 2.2,  then we need to hold it in a feature branch.
(09:04:57 AM) uebera||: Would be good to see whether any of these are still part of a support Linux/BSD/... distribution.
(09:05:08 AM) vrurg: gac410: I suggest major. It is hard to explain to an end user why he would need to upgrade his perl for another 2.x
(09:05:12 AM) uebera||: s /support/supported/
(09:06:05 AM) gac410: uebera||:  The problem as usual is the LTS releases with very very long support lifetimes.   I think that centos/rhel  still has supported releases with old perl.
(09:06:22 AM) jast: RHEL5 with perl 5.8 still supported, RHEL6 with perl 5.10 still supported
(09:06:29 AM) JulianLevens: I could make the use Unicode::Collate::Locale conditional on perl version and just use NFKD otherwise
(09:06:45 AM) uebera||: Uh. good to know, thanks jast.
(09:06:46 AM) MichaelDaum: I stopped using the standard perl for performance reasons ... no matter which distro
(09:07:00 AM) jast: FWIW support for RHEL5 ends in 2020
(09:07:20 AM) gac410: RHEL4 ends in the beginning of 2017
(09:07:36 AM) MichaelDaum: "still supported" by redhat, not perl upstream
(09:07:44 AM) jast: yeah, obviously
(09:07:49 AM) andreli: Yeap, upgrading to 5.22.1 with plenv resulted in a huge performance boost.
(09:08:00 AM) jast: what this means is corporations are likely to keep perl <5.12 around for quite a long time still
(09:08:37 AM) MichaelDaum: it might be worse spending some braincycles on freeing ourselves from these distro dependencies
(09:08:45 AM) MichaelDaum: perl will remain unloved for quite some time
(09:08:54 AM) MichaelDaum: alas we need to go forward
(09:08:54 AM) jast: the downside of plenv and friends is that security updates are a huge pain
(09:08:56 AM) andreli: I guess, with Foswiki pushing Unicode, I would be understood if it pushes siutable perl version too.
(09:09:01 AM) gac410: I guess my opinion is that if corp wants to keep very old perl,  then they can stay on very old foswiki.  
(09:09:20 AM) uebera||: good point.
(09:09:28 AM) MichaelDaum: gac410, which of course is a security issue of its own
(09:09:30 AM) gac410: ie  I'm willing to leave them behind.   Lavr has been the most vocal opponent of this.
(09:10:02 AM) MichaelDaum: if only we had procedures to auto-compile things behind the scene using ConfigurePlugin
(09:10:06 AM) uebera||: And nowadays, there are container everywhere (with different risks, side effects), but it's easier to "Jail" an environment/service.
(09:10:07 AM) jast: we have customers who are still on RHEL5, you can imagine I wouldn't be absurdly happy if support was dropped
(09:10:42 AM) jast: and that's all I'm going to say on this. I don't want to drag this out unnecessarily.
(09:10:54 AM) gac410: Just leave them on older foswiki.  How can you possibly expect shiney new features to run on ancient systems.
(09:11:02 AM) MichaelDaum: gac410, +1
(09:11:25 AM) MichaelDaum: but mind you: rational on that level is not always driven by logic
(09:11:26 AM) jast: well..... we've had customers who expected built in automatic and error-free machine translations of wiki topics
(09:11:37 AM) vrurg: uebera||: Containers won't work in multidomain setups, BTW.
(09:12:00 AM) jast: let's just say people are capable of expecting lots of interesting things
(09:12:11 AM) MichaelDaum: vrurg, why?
(09:12:42 AM) jast: containers in multidomain setups are more of a pain to set up, but not fundamentally impossible
(09:12:43 AM) JulianLevens: Ok, "back to the feature", I'll conditionally use Unicode::Collate::Locale to negate dependency on recent perls but users of recent perls will get full collation support
(09:12:45 AM) vrurg: MichaelDaum: Wrong expression. They won't completely protect – that's more correct.
(09:13:15 AM) gac410: well  status quo with foswiki 2.x  is ... sites running perl < 5.22 have a huge performance challenge.    so in some ways we've already left the old sites behind.
(09:13:24 AM) jast: I'm fine with that approach
(09:13:31 AM) uebera||: vrurg: maybe we should discuss this separately as well (I'm interested, but don't have the time for that atm)
(09:13:32 AM) jast: (locale)
(09:14:30 AM) gac410: I'd suggest that we try to avoid *breakage*   on old perl.   ie,  we don't put in  use perl v5.14.    unless we really have no choice.  at least for foswiki 2.2.    3.0   is still open to force new perl.
(09:14:49 AM) MichaelDaum: vrurg, VirtualHostingContrib is just fine ... as long as it is okay to share plugins, apps, locales.
(09:14:52 AM) vrurg: uebera||: I might be mistaken as well. Trying to rethink the thought I've got and it doesn't seem that convincing anymore.
(09:15:02 AM) jast: side note, the checkin fields in Item14004 haven't gotten populated by my push
(09:15:09 AM) jast: something broken?
(09:15:30 AM) gac410: I'll check 
(09:15:52 AM) vrurg: MichaelDaum: One of the reason for my project: I won't completely per-domain localized staff. Including plugins, etc.
(09:16:12 AM) jast: I noticed the // operator in Foswiki::Locale::Load. I believe this operator was added in perl 5.13
(09:16:13 AM) gac410: jast.   Cache.    It updates on trunk.
(09:16:14 AM) vrurg: I want ....
(09:16:20 AM) jast: oh, okay
(09:17:01 AM) vrurg: jast: It's in perl since 5.10
(09:18:27 AM) JulianLevens: good catch, I'll change that
(09:18:28 AM) jast: oh, good
(09:18:41 AM) gac410: So with regard to release planning..    we are approaching 4 months before 2.2     Is everyone with a feature slotted for 2.2   for a feature freeze,  let's say June 1  
(09:19:08 AM) CDot: +1
(09:19:15 AM) MichaelDaum: fine with me
(09:19:17 AM) JulianLevens: y
(09:19:43 AM) jast: I'm sure I'll manage to rush through another feature before then :)
(09:20:40 AM) gac410: Okay,  I'll update the release plan.   http://foswiki.org/Development/ReleasePlan     Feature freeze  June 1st 2016.   Release in July    
(09:22:10 AM) gac410: CDot ... If I branch TinyMCE and load in the latest version into an Item branch,  would you have some time to work on retrofitting the tmce exits?     I'll share the work, but js. isn't my forte 
(09:23:54 AM) gac410: They are up to 4.3.7,  and we are still stuck on 3.5.x, ...   They don't even have 3.5 listed on the download old releases page any more.
(09:24:29 AM) MichaelDaum: I am currently working on NatEditPlugin to "enginify" it
(09:24:43 AM) MichaelDaum: this is a reworked way how editor backends are loaded into the natedit shell
(09:25:06 AM) gac410: okay.  in that case are you saying we should hold off on any attempt to upgrade tmce?
(09:25:18 AM) MichaelDaum: so we can switch on multiple such as raw (current natedit engine), codemirror, and tinymce4
(09:25:26 AM) MichaelDaum: yes
(09:25:29 AM) gac410: okay
(09:25:47 AM) MichaelDaum: the current TinyMCEPlugin's javascript code is not worth keeping alive for another decade
(09:26:25 AM) gac410: Would the old non-js text editor still be usable  (with natedit removed from skin) ... there are some sites still objecting to the heavy js requirement
(09:26:49 AM) MichaelDaum: they simply have to switch off natedit from SKIN
(09:26:52 AM) MichaelDaum: like 2day
(09:26:55 AM) gac410: okay... good.   
(09:27:07 AM) gac410: just making sure we didn't forget about that mode 
(09:27:24 AM) MichaelDaum: that remains status quo as implemented by skins
(09:27:40 AM) gac410: Okay everyone .... any other business ... plans to review?   Feedback ? 
(09:27:45 AM) MichaelDaum: i.e. only pattern and default skin can do that
(09:27:56 AM) gac410: yes that's find MichaelDaum   
(09:28:03 AM) gac410: fine
(09:28:15 AM) MichaelDaum: btw codemirror is really nice to edit tml with
(09:28:29 AM) gac410: What about ckeditor ?
(09:28:31 AM) MichaelDaum: it hilites while you edit
(09:28:41 AM) gac410: cool
(09:28:49 AM) MichaelDaum: I am currently working in an image-widget so that images can be d&d'ed within codemirror
(09:29:02 AM) MichaelDaum: ckedit not looked into its api
(09:29:12 AM) MichaelDaum: maybe easier to deal with than tinymce4 ... which is a beast
(09:29:20 AM) gac410: I think jast has done the most with that one
(09:29:35 AM) gac410: there is an old ckeditor contrib - no idea if it's still usable.
(09:29:49 AM) MichaelDaum: it only works with model-aachen's foswiki fork
(09:29:50 AM) jast: WysiwygPlugin can't cater for both TinyMCE and CKEditor
(09:29:57 AM) jast: their ways of mangling HTML are too different
(09:30:00 AM) jast: it's a huge mess
(09:30:52 AM) MichaelDaum: the new natedit will give you those editors in EditChaterPlugin as well
(09:30:59 AM) jast: in our plugin we've basically accepted that a HTML/TML roundtrip will completely destroy spacing
(09:31:12 AM) gac410: yech..   That just wouldn't fly  
(09:32:02 AM) jast: I spent a few days on polishing up CKEditorPlugin to make it available without all our stuff, but eventually I gave up
(09:32:09 AM) CDot: gac410: time, no, very limited. I already have a branch with the lkatest TMCE, but it's behind FW by some considerable way
(09:32:38 AM) gac410: Okay everyone ... Thanks muchly.     I'll get notes posted later.    Please don't forget to comment on proposals in the 14 day clock!   
(09:33:02 AM) gac410: CDot:   okay thanks.  Sounds like MichaelDaum's changes will hold that off anyway.
(09:33:11 AM) CDot: ok
(09:34:37 AM) gac410: Btw.   vrurg's   Item13897   is working pretty well with Moo now.   I merged master into it over the weekend  so it's up to date.   *definitely* not compatible with existing extensions yet.   
(09:34:46 AM) gac410: But nice to see it's quite functional 
(09:35:14 AM) vrurg: gac410: Hm, even with finish() removed?
(09:35:22 AM) gac410: Oh... didn't try that yet   :D
(09:35:27 AM) vrurg: Ok.
(09:35:53 AM) vrurg: I know what's causing the clean up warnings but that's a weird issue. Perhaps a Moo bug.
(09:36:33 AM) gac410: well  webhome renders,  but editrow plugin fails with unable to find finish() 
(09:36:54 AM) gac410: configure works
(09:36:55 AM) vrurg: BTW, Do we have changes in proposal topics reflected in RSS feed?
(09:37:26 AM) gac410: http://foswiki.org/Development/WebRss   
(09:37:50 AM) gac410: But the reported information in the feed is pretty useless IMO
(09:38:04 AM) vrurg: gac410: Just removed that ->finish in editrow if you want. Maybe replace with undef for certainty.
(09:38:55 AM) CDot left the room (quit: Quit: Leaving.).
(09:38:56 AM) gac410: Anyway ... everyone... Thanks    That's a wrap.        
(09:46:06 AM) andreli left the room (quit: Remote host closed the connection).
(09:47:08 AM) vrurg: thanks!