Release Meeting: 4 Apr 2016

(08:30:08 AM) Lynnwood [~Lynnwood@foswiki/developer/lynnwood] entered the room.
(08:59:33 AM) gac410: Hi all
(08:59:51 AM) gac410: https://foswiki.org/Development/ReleaseMeeting02X02_20160404
(09:01:36 AM) andreli entered the room.
(09:01:46 AM) gac410: Shall we get started?
(09:01:54 AM) MichaelDaum: hi guys
(09:01:58 AM) andreli: hello
(09:02:01 AM) jast: hi everyone
(09:02:11 AM) uebera||: Hi there
(09:03:25 AM) gac410: First up ...   Urgent tasks review.     The 2 urgents related to json::xs    It appears they are an upstream xs issue running under mod_perl.   
(09:04:17 AM) gac410: So if possible, someone needs to push them upstream.   Not much we can do I don't think other than document them as known issues under mod_perl
(09:05:34 AM) MichaelDaum: what about this flag?
(09:05:41 AM) MichaelDaum: does it cause any harm?
(09:05:55 AM) MichaelDaum: allow_something
(09:06:06 AM) gac410: yeah   allow_nonref
(09:06:21 AM) gac410: jast ... I think you were running with that.   Do you think it's safe?
(09:06:57 AM) jast: should be fine in JQueryPlugin as we generate the structure ourselves
(09:07:23 AM) jast: hang on a sec to let me check the other one...
(09:07:32 AM) uebera||: IIRC, setting this flag just means that no error will be raised. If it's unneeded (as it should be w/o the bug), it's ignored.
(09:08:12 AM) gac410: So in that case maybe we should patch this for 2.1 / 2.2    Though it would be best if someone would open an upstream but item.
(09:08:52 AM) gac410: Any volunteers   (jast?)   :D
(09:08:56 AM) jast: yeah, should be fine in JsonRpcContrib, too
(09:09:01 AM) MichaelDaum: at least there is somethign we can be proactive about ... mitigating strangeness via this magic switchoid
(09:09:45 AM) jast: fine, I'll do it
(09:10:14 AM) gac410: great  Thanks!
(09:13:31 AM) gac410: So for the cache,  looks like we need another index.    And we at need to make System.ParentList non-cachable.
(09:14:14 AM) gac410: Those are https://foswiki.org/Tasks/Item14037 and https://foswiki.org/Tasks/Item14038
(09:14:55 AM) gac410: I'd say delete System.ParentList,  but it might be being used in other wiki applications.
(09:16:16 AM) gac410: Only other thing that probably ought to have a blocker opened.    The EditRowPlugin,   "whole table edit function"   I noticed that cancel does not actually cancel, and updates get saved.
(09:17:05 AM) gac410: I think that deserves a blocker.   otherwise I'd say we could be ready to build 2.2.1 soon.
(09:17:12 AM) JulianLevens  entered the room.
(09:18:28 AM) gac410: I think that finishes blocker discussion.    Now on to features ??
(09:18:33 AM) gac410: (Hi JulianLevens)
(09:18:54 AM) JulianLevens: HI
(09:19:27 AM) gac410: Last call for https://foswiki.org/Development/SplitArgumentsinMAKETEXT       There have been no comments on that proposal
(09:20:00 AM) gac410: So I guess after today jast, it can flip to accepted and ready for you to implement.
(09:20:09 AM) jast: yay :)
(09:21:12 AM) gac410: I don't think that there have been any other proposal status changes or development ... vrurg,  do you need to get any feedback on anything?
(09:22:03 AM) jast: are the JSON::XS items targeted for 2.1.1 or 2.2?
(09:22:23 AM) gac410: I think that could go into 2.1.1 ... It's a bugfix
(09:22:36 AM) jast: okay, I'll update the items
(09:24:51 AM) jast: btw, does anyone periodically merge 02x01 into master?
(09:25:29 AM) gac410: Usually I cherry-pick from master into 02x01
(09:25:51 AM) jast: typically the easier approach is to fix things in the maint branch and merge to master
(09:26:21 AM) gac410: y,  I think I've finally realized that,  but I suspect I've messed things up by cherry-picking in the other direction.
(09:26:30 AM) jast: usually git can figure it out anyway
(09:26:38 AM) gac410: Not sure what a merge would do now.      oh... cool.
(09:26:41 AM) jast: you'll have some duplication in the commit logs but who cares
(09:26:54 AM) jast: so, for the record, I'm committing this to 02x01 :)
(09:27:42 AM) gac410: Okay ... that's a good thing to remember.  The other advangtage of a merge vs. cherry-pick is that the md5 stays consistent
(09:28:12 AM) gac410: Please also update the extension change logs, and if necessary bump the extension versions.   ;)
(09:28:44 AM) jast: good point
(09:28:48 AM) jast: almost forgot about that
(09:29:01 AM) jast: in fact, s/almost //
(09:30:05 AM) gac410: I'm making good progress with the restructuring of Foswiki::Request.    Minor tweak to the Engine suggested by Vadim  makes it easy.   Changes in the Item14038 branch will be planned for 2.2
(09:30:14 AM) vrurg: I'm just saw a notification from my client, came to answer. :) Sure, any feedback is useful. Specially while it's on rather early stage.
(09:30:40 AM) jast: does $RELEASE in distro extensions get bumped only when the whole thing gets released?
(09:31:42 AM) gac410: Usually it's better to bump it on the first commit after the last release.  So your poor RM doesn't forget to do it, and need to re-release ... Like he did with 2.1
(09:31:52 AM) gac410: :D
(09:32:13 AM) jast: because in JsonRpcContrib it's about three updates behind :)
(09:32:28 AM) jast: and the date in $RELEASE doesn't correspond to _any_ changelog entry
(09:32:54 AM) jast: it's not easy to see which extension version was released in which foswiki version
(09:32:57 AM) gac410: So on 2.2 features   ... just a reminder.   It's april,  and we planned 2.2 for June/July    So features should be starting to show up in master.
(09:33:32 AM) gac410: jast  y,   unless I someone remembers to add an explicit "Released with Foswiki x.x"  into the change log,  it's a fishing expedition.
(09:33:59 AM) jast: okay, so at least I'm not missing anything, that's good to know :)
(09:34:32 AM) jast: I'll just bump it anyway, no harm done IMO
(09:34:56 AM) gac410: What I usually do (when I remember)   is "git log SomeExtension"   and look at the top commit,  and see if the release needs bumping.   It a pain.
(09:35:46 AM) gac410: Y,   It's one reason I don't like dates as the version strings.    The date should reflect the last change,  where a simple incrementing version just needs to change once between releases.
(09:37:27 AM) gac410: So for those exts,   need to check the git logs,  and make sure that the date of the last commit is reflected in the RELEASE string,  otherwise,  needs another update.   ... and check the change logs,  etc.
(09:38:00 AM) MichaelDaum: version=float-or-version-tag, release=date-of-latest-version-bump
(09:38:48 AM) MichaelDaum: not the last checkin. but the last checkin that also bumped the version string. might be in the middle of a series of fixes til the next release is ready to go.
(09:39:02 AM) gac410: I always figure release = date of last change.  Otherwise it "appears"  that there were changes made after the release.
(09:39:33 AM) jast: gah, why is the hook rejecting my commit :C
(09:39:40 AM) jast: it talks about item numbers totally unrelated to what I did
(09:40:17 AM) gac410: If I see "Release: 14 Mar 2016"     and see changes in the git log after that date,  that tells me that I need to rebuild and release the extension MichaelDaum
(09:40:44 AM) gac410: Jast,   the help message has "example" ite numbers in it  iirc.
(09:41:31 AM) jast: oh, I see, it doesn't like my -v flag
(09:41:50 AM) jast: nasty, but I can work around that
(09:41:56 AM) gac410: -v flag? 
(09:42:14 AM) jast: git commit -v shows the diff under the commit message
(09:42:24 AM) gac410: ah
(09:42:29 AM) jast: it gets removed before the actual commit message is created but apparently the hook scans that for item numbers, too
(09:43:00 AM) MichaelDaum: gac410, which extension
(09:43:20 AM) gac410: Any extension.   It's one of the things I have to check when building a new release.    
(09:43:38 AM) gac410: If the extension dates appear to indicate missing commits,  then I have to inspect each commit.
(09:43:55 AM) MichaelDaum: ?
(09:44:33 AM) MichaelDaum: they have items in WaitingForRelease
(09:44:44 AM) gac410: If I look in the Extensions web,  or the configure extensions list and see an extension date of January,  and see commits in February,  then obviously someone has missed some commits.
(09:44:59 AM) MichaelDaum: no
(09:45:33 AM) MichaelDaum: core extensions ready to be released may be pre-released in Extensions/Testing as is the case with JQueryPlugin
(09:46:03 AM) MichaelDaum: so no surprise you are seeing old extesions in Extensions ... yet newer commits on master
(09:46:11 AM) gac410: Sigh... another argument.     Yes.  I cannot *trust*   that everyone always gets everything right.      So if the RELEASE date in the module is OLDER than  recent commits,  then I need to check.
(09:46:31 AM) gac410: It's just a flag that something might be missed.
(09:46:53 AM) gac410: And yes,  sometimes I find things that were missed.
(09:47:01 AM) MichaelDaum: what if you just caught an extension in the middle of a series of commits?
(09:47:23 AM) MichaelDaum: and this series isnt over yet. so no release and no RELEASE and no VERSION bumped
(09:47:28 AM) gac410: If I am building a Release,   then I better not be catching stuff in the middle of a set of commits.
(09:47:59 AM) MichaelDaum: right. and thats when you need to contact the committer
(09:48:11 AM) MichaelDaum: "is your stuff ready to go" kinda thing
(09:48:13 AM) gac410: So If I annoucnes that we will build 2.1.1 on April 15th    at that point  I hope there is nothing partially committed.       And I review every extension.
(09:48:43 AM) gac410: And if I see a RELEASE string older than the last commit,   Now I wonder if it got bumped in the first place,  So I start digging further.
(09:49:24 AM) gac410: You do them one way,  everyone else does things slightly differnetly  (including not updating at all) ... so I have to chekc every darn one every time.
(09:49:59 AM) gac410: Not saying you are wrong or right.  Just that I have to manually check every inconsistency.   And commits newer than the release date tells me they they were maybe missed.
(09:50:37 AM) MichaelDaum: just tell us how we can do things in a way that it works out best 4u
(09:50:40 AM) jast: JSON::XS stuff committed and merged
(09:50:49 AM) MichaelDaum: not that easy it seems
(09:50:52 AM) gac410: Excellent!   Thanks jast.    
(09:51:36 AM) gac410: I don't know if there is a good way MichaelDaum ... In some  (many?)  cases I'm my own worst enemy,  as I  forget to get it right too.    
(09:52:38 AM) gac410: It's just a whole mess of consistency checking I have to do.    Review master commits,  were any bugfix that should have been merged.    Review versions and release dates,  were any not bumped,   review change logs ... 
(09:53:15 AM) gac410: And jast .. your comment about "Fix on the release,  merge to master"   Is a VERY IMPORTANT point.    Everyone.    We need to work that way if at all possible
(09:54:19 AM) gac410: We cannot merge from Master to Release branches.     So if the source is master,  we have to cherry pick one commit at a time,  Or do the nasty "Sync up with master"   commit
(09:55:03 AM) gac410: Big features =>  Item branch, merge to master.     Small features  => master.     Bugfix   =>  release branch,  merge to master.
(09:57:31 AM) gac410: jast   when you merged release02x01 into master,   did you run into any issues?  
(09:57:32 AM) MichaelDaum: ah thats new for me
(09:57:48 AM) jast: gac410: I had a few conflicts, probably due to cherry picks or something, but they were trivial to resolve
(09:58:10 AM) gac410: New for me too.    I knew I would prefer to see merges,     but merge has always scared me.   I've really messed myself up a few times.
(09:58:46 AM) gac410: But I did a merge from master => Vadim's  feature branch,   and it went very well.   so I was becoming a bit more comfortable.
(09:59:01 AM) jast: two simple rules to avoid excessive pain: don't push a merge if you're not sure about it, and don't rebase/reset stuff you've pushed
(09:59:29 AM) ***MichaelDaum is just a dump git user
(10:00:53 AM) MichaelDaum: gotta work on stuff. back later.
(10:00:56 AM) MichaelDaum is now known as MichaelDaum_
(10:00:58 AM) gac410: The challenge with merge,   it is all or nothing.   So merge  Release => master  is safe.   But master => release is a huge NO    because it would take all features.
(10:01:03 AM) jast: exactly
(10:01:54 AM) gac410: Okay everyone ...   1 hour in the release meeting.      Thanks 
(10:02:32 AM) gac410: If someone has a chance to play with EditRowPlugin,  and test the "whole table edit"    "cancel"  vs.  "Save"   that would be great.   I thinkn that there is an urgent bug there.