Release Meeting: 10 Aug 2015

(08:08:40 AM) andreli entered the room.
(08:48:50 AM) Lavr entered the room.
(08:49:26 AM) JulianLevens entered the room.
(09:03:00 AM) andreli: Hi
(09:03:15 AM) gac410: Hi all....   Welcome to the release meeting   
(09:03:16 AM) jast: hi André
(09:03:22 AM) andreli: Hello Jan
(09:03:22 AM) MichaelDaum: hi all
(09:03:22 AM) jast: oh, and hi everyone else :)
(09:04:12 AM) gac410: I didn't put much on the agenda - just blocking task review.    http://foswiki.org/Development/ReleaseMeeting02x01_20150824
(09:05:37 AM) gac410: http://foswiki.org/Tasks/Item13525    Michael's fix for the excessive topic read.   I downgraded that to normal,  I think we agreed at the last meeting.
(09:06:38 AM) gac410: http://foswiki.org/Tasks/Item13560     The configure issues related to external installers (unzip, git, pseudo...)   Is mostly fixed. Crawford suggested some cosmetic improvements, so I've left it open.
(09:07:17 AM) jast: sounds good
(09:07:35 AM) gac410: http://foswiki.org/Tasks/Item13561   The uglification of perl hashes in configure.   I think that's ready for release.  Michael - we discussed some about the data dumper prettying  but still left waiting for your feedback.
(09:08:33 AM) gac410: http://foswiki.org/Tasks/Item13598   rename of Symlinked web in PlainFile.   WaitingForRelease.  Crawford reviewed my fix,  and the code seems to do the right thing. 
(09:09:31 AM) gac410: And for the serious blockers.   http://foswiki.org/Tasks/Item13570    EditRowPlugin and TablePlugin interaction issues.    I was hoping CDot could report further.  He says it will be difficult to fix  :(*
(09:10:03 AM) gac410: The issue is that TABLE macros are parsed out by core without any knowledge of other *TABLE macros.  
(09:11:09 AM) gac410: As the two macros work if they are on the same line,  I was wondering if a temporary hack would be to use an early handler to append the macro lines and sidestep the issue.
(09:11:37 AM) gac410: But I think that really needs Crawford.
(09:11:40 AM) jast: this would be rather ugly, but the affected plugins could set a context to let core know to change the processing
(09:12:17 AM) gac410: yeah,  or even an exit in the TABLE parser to handle other table related macros.   But all that is pretty ugly I suspect.
(09:12:36 AM) jast: definitely
(09:12:58 AM) gac410: I suppose really Exits and/or contexts  would need proposals as they are API changes   :(
(09:13:44 AM) gac410: And last blocker is for you Michael.   http://foswiki.org/Tasks/Item13629     Lavr is concerned with the default Summary field in the editor.
(09:14:09 AM) MichaelDaum: basically he is right
(09:14:13 AM) andreli: I don't see this as a blocker
(09:14:48 AM) MichaelDaum: to make sense of this field the related - unimplemented feature - needs to be extended a bit
(09:15:29 AM) gac410: Y.   I agree andreli   I probably wouldn't let it block a release.  But it is annoying noise for end users who would not understand what it's all about.
(09:15:45 AM) MichaelDaum: this field is used to specify the "Topic Title" ... that might be different from the "Topic Name" as it appears in the URL
(09:16:22 AM) gac410: But it also relocates the Summary field in our Tasks web.    So more than just Topic Title
(09:16:23 AM) MichaelDaum: the topic title is a free-form text field that specifies the link text of the WikiWord that of this topic
(09:16:37 AM) MichaelDaum: gac410, thats something I added as part of BugsContrib
(09:16:43 AM) gac410: Ah... okay
(09:16:52 AM) MichaelDaum: QuestionForm does make use of it on F.O.
(09:17:06 AM) gac410: Yes I noticed that as well
(09:17:09 AM) MichaelDaum: as it already has got a TopicTitle field ... the standard formfield being used in this form element
(09:18:11 AM) gac410: It would probably be nice if it could be 'switched off' for webs or topics that don't use it for now.   But I don't believe we should delay 2.0.2 for that one.
(09:18:15 AM) MichaelDaum: I'd suggest we disable this field for 2.0.x and add it back in 2.1.x when http://foswiki.org/Development/TopicDisplayName is fully implemented
(09:19:16 AM) gac410: Could it be configurable,  so that it survives in our Tasks & Support web,  or is that too hard.  Just disable it and revert to the originial behaviour in tasks/support
(09:19:19 AM) MichaelDaum: Lavr is probably not aware of the reasoning behind having a separate "Topic Title" in Foswiki .... similar to other CMSes
(09:19:58 AM) gac410: right.  He is monitoring, so maybe he'll see his name  :)   
(09:19:59 AM) MichaelDaum: btw this is not related to NatSkin.
(09:20:20 AM) Lavr: I think the feature is great but it just needs some tweak so it can be disabled when having a data form OR the field defined to be a field from the form
(09:20:50 AM) MichaelDaum: DBCachePlugin and a couple of other plugins make already use of a TopicTitle being either stored in a formfield called "TopicTitle" or in a preference setting called TOPICTITLE otherwise
(09:21:14 AM) MichaelDaum: DBCachePlugin the implements a renderWikiWordHandler that reads these properties 
(09:21:52 AM) MichaelDaum: we had a couple of clients that have a similar problem with NatEdit for the same reason as Lavr outlined
(09:21:58 AM) MichaelDaum: lots of legacy wiki apps
(09:22:00 AM) gac410: Cool    ... So you don't have to use the [[WikiWord][Some meaninful topic reference]]
(09:22:37 AM) MichaelDaum: with a Title formfield (or ProjectTitle, FooBarTitle, you name it title) that is meant to be used as the "topic title" of a specific kind
(09:23:04 AM) MichaelDaum: an extension to the TopicDisplayName feature would be to make this configurable: which formfield is used as a TopicTitle
(09:23:12 AM) MichaelDaum: maybe a comma separated search list
(09:23:18 AM) gac410: Okay  so sounds like there is agreement,  just timing ... for 2.0.2 or 2.0.3  with some way to inhibit the field from edit except when needed / desired.
(09:23:47 AM) MichaelDaum: TOPICTITLE_FIELD = TopicTitle, Title, ProjectTitle, Question, Summary .... 
(09:24:15 AM) MichaelDaum: and then Foswiki::Func::getTopicTitle($web, $topic) / Foswiki::Meta::getTopicTtile() deal with it accordingly
(09:24:23 AM) gac410: yeah  that would be nice.    And then a view template that will render it as the page H1   and as you comment the renderWikiWordhandler
(09:24:42 AM) MichaelDaum: xactly
(09:25:35 AM) MichaelDaum: even http://en.wikipedia.org/wiki/Special:Search?go=Go&search=%TOPIC% would be rendered as [[Web/topic][topic title]]
(09:25:40 AM) MichaelDaum: even [![%TOPIC%]] would be rendered as [[Web/topic][topic title]]
(09:26:14 AM) gac410: Okay,    pulling over the discussion from #foswiki.   We have the Ldap crash with _[a-f][a-f]  in a login name / cUID.   but what bumps this to urgent.  I can't see how to make ACL's work when the allowLoginname is enabled.
(09:27:16 AM) jast: has someone combed through that code path yet?
(09:27:19 AM) gac410: I think someone else reported that ...  need to dig around.
(09:27:27 AM) jast: 13177?
(09:27:36 AM) jast: or is that a different issue
(09:27:58 AM) gac410: I'm not sure yet if they are the same issue or a separate problem. 
(09:28:06 AM) andreli: My issue is reported in http://foswiki.org/Tasks/Item13630
(09:28:31 AM) jast: yeah, that's related but not the same error
(09:28:36 AM) gac410: I think the Ldap crash ... MichaelDaum recreated it .. .is specific to LdapContrib 
(09:28:36 AM) MichaelDaum: I have successfully reproduced the error
(09:29:45 AM) gac410: The ACL issue is different,  but maybe related to ... or is  http://foswiki.org/Tasks/Item13177 [ Item13177: when loginName contains specials, $SESSION->{user} double-encoded as a cUID when passed to checkAccessPermission() ]
(09:31:12 AM) gac410: I think my conclusion was that the fix was very difficult / impossible without rewrite.  But bottom line is that ... if the login name contains underscore,  then you cannot use the WikiName in an ACL.
(09:31:33 AM) jast: specifically, underscore + [0-9a-f]{2}, right?
(09:31:33 AM) gac410: er  I should probably make that 'our conclusion'   ;)
(09:31:59 AM) gac410: I'm not sure ...    That is definitely one case.   I need to test some more.  
(09:32:37 AM) gac410: The hacking in of cUID is really ugly.    Done a long time ago.  in a place far far away  :)
(09:32:44 AM) jast: I agree that the only proper fix is a rewrite. anything else will probably leave us with subtle defects.
(09:32:50 AM) andreli: As we are migrating from a 1.1.x Foswiki with lots of usernames matching above pattern, I say this is a newly introduced bug/limitation
(09:33:39 AM) jast: FWIW we did some performance tests recently and managed to conjure up a wiki that took two minutes per page view, with a massive LDAP. we managed to reduce that to 0.5 seconds by overriding a lot of the logic in the mappers... but killed many features in the process
(09:34:34 AM) gac410: andreli:  yes,  the task is marked as trunk.  So it doesn't seem to apply to 1.1.9.    Not sure where / how it got introduced though.
(09:34:54 AM) jast: the "wide character" error is due to the switch to unicode
(09:34:58 AM) jast: the underlying issue... who knows
(09:35:36 AM) gac410: the wide error seems to be LdapContrib only.    I could not recreate it using TopicUserMapping.   But the ACL issue is ugly.
(09:36:28 AM) andreli: Item13177 looks like pre 2.0, but http://foswiki.org/Support/Question1646 and Item13630 are specific to 2.0
(09:36:34 AM) Lynnwood entered the room.
(09:37:58 AM) gac410: I wonder then if there is a 3rd issue.   Item13177 seemed to be related to "special characters",  where as the ACL issue is related to underscore [a-f0-9]{2}
(09:39:16 AM) gac410: I tried to patch in a fix to 13177 but it broke things badly iirc
(09:39:21 AM) jast: so both the login2cuid and cuid2login transforms are broken, or used too often, or not used enough, or both
(09:41:01 AM) gac410: y.    and the api docs lie.   It states outright that getCannonicalUserID should never be called with a cUID,  but the core calls it anyway.   Heck Foswiki::Func documents that you DO call it with a cUID.
(09:42:02 AM) gac410: Anyway,  regarding 2.0.2 release,   I don't think this one can/should block 2.0.2   Too many other important fixes to get out.  Especially the performance fix.
(09:43:12 AM) gac410: Anyway,  that was the end of my list of blockers.   Does anyone want to nominate any other bugs for 2.0.2?    I was planning on releasing it around the beginning of September.
(09:44:03 AM) gac410: For now I'm suggesting that we stick with a monthly patch release to get the urgent issues resolved.   So anything that doesn't make 9/1 will slip to 10/1 or thereabouts.
(09:44:30 AM) gac410: Once we have no urgent tasks pending, we can move onto the 2.1 feature discussions.
(09:45:09 AM) gac410: Oh... and speaking of violating the rules :(    I slipped in some core template changes into 2.0.2  ... I *removed* the RevCommentPlugin conditional expansions in core.   
(09:45:55 AM) gac410: RevCommentPlugin is currently not functional on 2.0,  and I have an updated version about ready for release that adds all the necessary overrides by using a skin template override.
(09:47:24 AM) gac410: So I've "removed" a core feature accommodating a non-default extension.   I rationalized my way into removing a feature in that it's broken and has an alternate and cleaner implementaiton.
(09:48:38 AM) jast: personally I don't mind :)
(09:48:54 AM) andreli: fine with me. Looking forward to 2.0.2
(09:48:54 AM) gac410: Anyone want to discuss any feature proposal or tasks in the remaining 10-15 minutes?
(09:49:29 AM) jast: just want to point out that tools/configure is not very self-documenting
(09:50:06 AM) gac410: tools/configure --help    ...   helps.    
(09:50:18 AM) jast: except it doesn't mention which values are valid for -wizard and -method and -args
(09:50:37 AM) jast: AFAICT the only way to find out is to read the code
(09:52:00 AM) gac410: Suggest some improvements.   It seems to say in the help ... for ex.   set key=value 
(09:52:00 AM) gac410:             Set the value of a key for -check, -wizard and -save.
(09:52:51 AM) gac410: Oh... you mean list the valid wizard names,  and method names?
(09:53:43 AM) MichaelDaum: andreli, there's a new patch at http://foswiki.org/Tasks/Item13630 that disables cUID <-> login conversion 
(09:53:59 AM) MichaelDaum: that is cUID === login after applying the patch
(09:54:11 AM) jast: gac410: yes
(09:54:13 AM) andreli: MichaelDaum: Thanks, I'll give it a try.
(09:54:42 AM) MichaelDaum: note that revision info of current topics might not point to the correct user anymore afterwards
(09:54:43 AM) jast: fair warning: the rcs binary will reject many login names if they're not cUID-ified
(09:55:03 AM) MichaelDaum: jast, such as which kind of logins?
(09:55:13 AM) jast: ISTR foo.bar was one of them
(09:55:50 AM) jast: another type of login name that is rejected, and *not* fixed by cUID conversion, is '123'
(09:56:11 AM) jast: i.e. anything with a leading digit
(09:56:27 AM) MichaelDaum: LdapContrib has got a flag "NormalizeLoginName" that might deal with it better than the cuid approach
(09:57:14 AM) jast: only bad news is when two login names are normalized to the same thing :)
(09:57:44 AM) MichaelDaum: thats very well possible depending on the ldap data
(09:58:05 AM) MichaelDaum: and how login attrs are extracted from it
(09:58:22 AM) MichaelDaum: ... and totally unrelated to cUID
(09:58:33 AM) MichaelDaum: as it currently is designed
(09:59:01 AM) jast: in short, no failsafe workaround exists
(09:59:41 AM) MichaelDaum: yep
(09:59:43 AM) gac410: y  the whole reason for the cUID mess is binary RCS iirc.   Moving to PlainFile and/or RcsWrap might allow the concept of cUID to just go away.
(10:00:06 AM) jast: okay, anything else? if not, I'll get back to debugging why Foswiki::Func::getListOfWebs dies in my wiki
(10:00:25 AM) MichaelDaum: it should have always been part of the RCS subsystem ... not part of the upper store layers nor the user mapping 
(10:00:41 AM) jast: not exactly
(10:00:51 AM) jast: part of the idea behind cUID is to support multiple login sources
(10:00:56 AM) andreli: MichaelDaum: patch works fine as far I could quickly get an overview.
(10:00:58 AM) jast: not that that ever panned out properly
(10:01:10 AM) MichaelDaum: andreli, could you check topics created with old cUIDs?
(10:01:28 AM) andreli: History?
(10:01:44 AM) MichaelDaum: jast, right. the current user code is not able to deal with multiple sources ... or even the same type of source twice
(10:01:44 AM) jast: yes
(10:01:47 AM) andreli: Oh yeah, broken :-(
(10:02:05 AM) jast: MichaelDaum: it could, but requires hardcoding IDs into the .pm files :}
(10:02:16 AM) MichaelDaum: shIDs
(10:02:49 AM) gac410: I hate to say it,  I suspect that once the cUID mess is really dealt with, it will involve another Store conversion   ... complex for sure.  dealing with ACLs too.  :(
(10:02:54 AM) jast: UnifiedAuth, if I ever get around to doing more work on it, will include a tool to convert/import LdapContrib cache.db files :)
(10:03:09 AM) ***MichaelDaum switching over good discussion to #foswiki on the user code
(10:03:24 AM) andreli: Ok
(10:03:26 AM) gac410: okay.    That's a wrap everyone.  Thanks!
(10:03:28 AM) jast: yeah, can we formally close the meeting?
(10:03:31 AM) jast: there we go
(10:03:35 AM) jast: see you in two weeks :)
(10:04:02 AM) gac410: Hopefully 2.0.2 will be released prior to our next meeting.