Release Meeting: 16 Nov 2015

(08:00:11 AM) gac410: Hi everyone.  ...   http://foswiki.org/Development/ReleaseMeeting02x01_20151116
(08:04:35 AM) MichaelDaum: Hi there.
(08:04:51 AM) gac410: howdy .... 
(08:05:08 AM) ***gac410 wonders if 1300z is too early now that daylight savings has ended?
(08:05:27 AM) MichaelDaum: my calendar says we are one hour ahead of our schedule for the rm
(08:05:41 AM) MichaelDaum: not that I trust it
(08:06:03 AM) gac410: Hm  Calendar not on zulu time?
(08:07:04 AM) gac410: I don't mind waiting an hour.  and we can push the future meetings to 1400Z
(08:08:42 AM) MichaelDaum: when I look at http://foswiki.org/Development/FoswikiCalendar, it says 15:00
(08:09:08 AM) MichaelDaum: probably depending on my browser settings. 
(08:09:12 AM) MichaelDaum: what is it for you?
(08:09:59 AM) gac410: blank.   Javascript errors.
(08:11:32 AM) gac410: Not working at all for me Michale.    I just go by the irc topic:   The topic for #foswiki is: Next Release Meeting: 16 Nov, 13:00Z   
(08:11:59 AM) JulianLevens: I expected the meeting to move an hour earlier, I don't care if we move the time or not
(08:12:37 AM) gac410: Doesn't matter to me.  I'm up early on Monday anyway ;)   Trash pick-up day and they come early 
(08:12:50 AM) MichaelDaum: JulianLevens, do you get a javascript error on http://foswiki.org/Development/FoswikiCalendar as well. gac410, what's the error in your browser console.
(08:14:00 AM) gac410: Never mind.   Fixed it.   My tracker blocker was blocking a tracking cookie 
(08:14:06 AM) jast: stupid google wants me to log in if I click
(08:14:22 AM) JulianLevens: Looks ok at 1st glance on Chrome
(08:14:38 AM) MichaelDaum: okay. thanks.
(08:14:41 AM) gac410: yeah it was me.    But it says the meeting is a t 3pm,   and it's 8am here.
(08:14:47 AM) jast: and the inline calendar gets removed by privacy filters, which I can hardly blame the page for :)
(08:15:17 AM) MichaelDaum: yea whatever you guys configure to your browsers
(08:15:32 AM) MichaelDaum: the event in there is 15:00 GMT+0 (London)
(08:15:59 AM) gac410: The event we always announce in the topic   is 1300Z   
(08:16:04 AM) MichaelDaum: sorry 14:00 GMT+0 ... and then should display according to your timezones
(08:16:25 AM) gac410: 1300Z is 1300GMT ... same thing.
(08:17:30 AM) gac410: When I highlight it here,   the calendar reports   "Mon, November 16, 3pm – 5pm"     Google is pretty broken here anyway.
(08:17:48 AM) MichaelDaum: okay fixed
(08:18:55 AM) jast: the important difference is that British time is not GMT during the summer :)
(08:19:38 AM) andreli entered the room.
(08:19:46 AM) MichaelDaum: can we start now?
(08:19:53 AM) JulianLevens: yes please
(08:20:06 AM) gac410: Okay lets go.
(08:20:21 AM) andreli: Oh, you didn't just wait for me :-)
(08:20:38 AM) gac410: I've built 2.0.3,   installed on Foswiki.org    and uploaded to sourceforge,  but NOT public yet.   
(08:21:00 AM) MichaelDaum: Thanks a lot George
(08:21:03 AM) gac410: There was still one blocker , appears to be only on foswiki.org, and I've been unable to debug it. 
(08:21:39 AM) gac410: I held off on 1.1.10,  CommentPlugin and TablePlugin unit tests fail.    and I'm hitting a wall on figuring them out as well.
(08:22:25 AM) gac410: Oh...   And I created the Release02x00   branch on github,  so...   We are open for FEATURES  !...
(08:23:09 AM) gac410: jast.   will you have some time to work on weblate in the next day or so.   Adding Release02x00 branch    and also we want to try adding some Extension repositories.
(08:24:01 AM) JulianLevens: What's the github flow? Is it documented on f.o somewhere?
(08:25:37 AM) gac410: We have so much git docs on f.o,  I get lost.   I'm pretty sure we've come to conclusion.    Branch for stable ... like 01x00  01x01  and now 02x00,   Develop on Item/Feature branches,    and merge into master when ready for testing/release
(08:25:37 AM) JulianLevens: gac410: didn't you add some states to Task forms to help with this?
(08:26:12 AM) gac410: Y.  Tasks has "Needs Merge",  and Feature form has a similar action.
(08:26:43 AM) JulianLevens: cool
(08:27:04 AM) gac410: So one issue on master,  that will effect feature branches.      It is not tidy.   There are 31 files that somehow escaped our tidy controls.
(08:27:15 AM) gac410: vurug discovered it.
(08:27:57 AM) gac410: So I can run a full tidy run ... but I have no idea if that is going to hurt the merge process.   Maybe we should get the feature branches merged, and then tidy.
(08:28:22 AM) JulianLevens: s/vurug/vrurg/
(08:28:50 AM) gac410: So for merge process.   I'm proposing.    We run a unit test on the feature branch.   If they pass, (and check for coverage!)   then we merge into master.
(08:29:14 AM) gac410: And we'll need to bring it up at a release meeting if there is zero test coverage.
(08:29:52 AM) JulianLevens: that works for me
(08:30:49 AM) gac410: We just keep it on the honor system... that Ready for Merge is claiming that unit tests are passing  ... that fair?
(08:31:22 AM) Lynnwood is now known as Lynnwood_
(08:31:44 AM) JulianLevens: y, just take away a virtual beer from any offenders ;)
(08:31:56 AM) gac410: :)
(08:35:10 AM) gac410: Okay,  So for 2.1 features.    Item13525 - Branch for Store performance, ...   MichaleDaum,   that's still experimental, right?
(08:35:51 AM) gac410: And JulianLevens:  Item13594 - Param+= set support ... Last meeting you said that is ready to go. but needs documentation.
(08:36:05 AM) JulianLevens: y
(08:36:20 AM) MichaelDaum: gac410, yes
(08:36:22 AM) gac410: Item13699 - Convert to Email::Simple ... that branch is ready to merge I believe. 
(08:36:49 AM) gac410: Item13740 - Security headers - ready for 2.1  
(08:37:25 AM) gac410:  Item13848 - Deprecate HTTP / HTTPS macros       I've got that one ready to go.  
(08:37:49 AM) gac410: As is  Item13849 - Make zones less intrusive   .... Michale reviewed that one for me.  And unit tests pass.
(08:37:54 AM) MichaelDaum: store performance is mostly brought down by noCheckinPending returning 0 ... means the store gets into a slow path on any file being changed on the cmdline, such as plugins being isntalled 
(08:38:51 AM) JulianLevens: that's another required tweak to the install process - it may even require a Store API enhancement
(08:38:55 AM) MichaelDaum: my current approach disables noCheckinPending ... which Cdot would rebel against when he was here
(08:38:59 AM) jast: I'm reconfiguring the translate server right now
(08:39:06 AM) gac410: okay jast .. Thanks.
(08:39:56 AM) gac410: Jast,  I think we'd like to try translating NatSkin    repostiory too.   Right MichaelDaum
(08:40:11 AM) gac410: Let's see how one works, before we go adding a bunch of them.
(08:40:30 AM) jast: sure
(08:40:49 AM) jast: just adding more RAM via the dog slow management interface right now
(08:41:06 AM) gac410: So... anyway,  that's the list of branches in github.    Now... Feature proposals.
(08:42:07 AM) gac410: http://foswiki.org/Development/ConfigurableURLIncludes .... MichaelDaum  That was yours.    Are you going to try for 2.1, or should we push that one out
(08:42:35 AM) MichaelDaum: I am in doubt that I will implement any of these features until 1 Dec
(08:43:09 AM) gac410: Okay.   So defer to 2.2.   or we decide to slip the 12/1  feature freeze date.
(08:43:42 AM) gac410: http://foswiki.org/Development/MakeItEasierToBlockSystemWebGuestAccess ... that one is mine.  It's just adding ACLs to system topics.  I can have that ready by 12/1
(08:44:01 AM) MichaelDaum: we have almost no progress on the master branch atm. nobody is working on 2.1
(08:44:24 AM) MichaelDaum: and 1 Dec is roughly 10 workingdays ahead...
(08:44:49 AM) MichaelDaum: even 1.1.10 and 2.0.3 are not yet out
(08:44:51 AM) gac410: huh?    i don't understand that one.       We have all these features pending in Item* branches.  We can merge them this week.
(08:45:29 AM) gac410: 2.0.3 just needs the release announcements ... it's ready to go and is uploaded (staged).   
(08:45:35 AM) MichaelDaum: we need them merged to master
(08:45:43 AM) MichaelDaum: well before any freeze
(08:45:57 AM) jast: in the commit messages for NatSkin in weblate, should we be using the same task Item as for distro?
(08:45:59 AM) gac410: Right.   That's not a huge effort I hope.
(08:46:08 AM) gac410: No.   We'll need a NatSkin task.
(08:46:08 AM) MichaelDaum: otherwise nobody else tests them
(08:46:37 AM) gac410: It was all waiting on me to branch 2.0.3    And I did that last night.  So Master is open for merge.
(08:47:09 AM) MichaelDaum: thats good to know
(08:48:02 AM) gac410: 1.1.10 would be ready if someone (cdot?)  could help nail down the failing unit tests.   CommentPlugin and TablePlugin.    The latter I'm 99.9% sure is a test issue.  But CommentPlugin might be an ACL issue so I'm holding off.
(08:48:09 AM) jast: I've added NatSkin to weblate. you can update the config to add a reference to the task Item once it's been created.
(08:48:21 AM) gac410: Great.  Thanks Jast
(08:49:30 AM) gac410: So... continuing on the feature proposals:   http://foswiki.org/Development/MakeZonesLessIntrusive .... is ready for merge and unit tests pass.
(08:49:36 AM) MichaelDaum: we've got 3 of 8 features ready to merge for 2.1, right.
(08:50:17 AM) MichaelDaum: 5 of them haven't even been started 
(08:50:33 AM) MichaelDaum: I can't see 1 Dec is still a sensible date
(08:50:58 AM) gac410: There are 2 more that have item branches ready to merge.   The web is just out of sync.
(08:51:15 AM) ***MichaelDaum looking at http://foswiki.org/Development/ReleasePlan
(08:52:11 AM) gac410: Right.   There is a disconnect between Item**** branches being ready,  and FeatureProposals being up to date.   That's why I first reviewed the github Item**** branches.
(08:52:57 AM) gac410: Anyway.  ages ago.  I thought we decided that we would try to release on a schedule.  If a feature is not merged by freeze date, it just slips from that release.
(08:53:37 AM) JulianLevens: y, we should stick to that if at all possible
(08:54:20 AM) andreli: My two cents following on the statement from MichaelDaum: Upgrading a Foswiki installation is still a lot of manual work. As much as I prefer updates often, the proposed improvements have to satisfy the work.
(08:56:16 AM) gac410: There are 2 features that are 1 day away from meeting the 14-day clock, and are ready to merge.
(08:57:58 AM) gac410: The only one that I suppose I'd consider a blocker is the backlinks issues.   JulianLevens   any progress on that one?    It's a big hole as the unicode changes make backlinks rather ugly.
(08:59:08 AM) JulianLevens: No real progress for months - I'll get stuck in this week and report progress asap
(08:59:47 AM) gac410: Okay thank.     Another major one   http://foswiki.org/Development/ReduceImpactOfCGIDotPMinFoswiki   ....    That one I think really needs to be deferred. 
(09:00:13 AM) gac410: I've done nothing at all on it.  and we resolved the issue that was making it urgent  (CGI deprecations)
(09:02:05 AM) Lynnwood_ is now known as Lynnwood
(09:02:32 AM) MichaelDaum: it's a cleanup job
(09:03:39 AM) gac410: Okay  so Should we slip 2.1 feature freeze date?    or go with a smaller release?     Or give everyone another week and see how the merge process goes
(09:04:18 AM) gac410: With the Branch / Merge process,  there is no "repository" reason that features cannot continue to be developed ... Nobody should ever wait on a branch.
(09:04:48 AM) gac410: Master may not be ready to take merges,  but Item**** branches should let work proceed.
(09:06:10 AM) MichaelDaum: Imho we should let go 2015
(09:06:42 AM) JulianLevens: I think that as we have release meeting just before proposed freeze we can make final decision then
(09:07:25 AM) MichaelDaum: and energize over the holidays to work on 2.1 starting january 
(09:07:29 AM) gac410: So we have 2 weeks to get the FeatureProposals merging done.
(09:08:22 AM) gac410: TBH I'm a bit reluctant to delay as well.    I'd like to see how the whole branch/merge process goes.  
(09:08:50 AM) JulianLevens: I'm not fighting to stick to 1st Dec; but I'd like to keep to that target and then see
(09:08:55 AM) MichaelDaum: why not merge an item branch to master as early as possible
(09:09:09 AM) gac410: Because then you cannot patch the prior release.
(09:09:22 AM) jast: if it's on a branch of its own (which it should be), then sure you can
(09:09:30 AM) MichaelDaum: ... which you just created a separate branch for last night
(09:09:38 AM) gac410: Right.   And we are ready to merge.
(09:10:08 AM) gac410: But we keep master releasable.  So merge when it's ready to release.         
(09:10:18 AM) MichaelDaum: having too many item branches hanging around not being merged to master is a danger of making things increasingly complicated over time
(09:10:30 AM) MichaelDaum: gac410, no
(09:10:46 AM) MichaelDaum: release branches are meant to be releasable
(09:11:02 AM) MichaelDaum: master is current work in progress
(09:11:06 AM) gac410: Master is our releasable branch.  It's the default branch to github
(09:11:12 AM) MichaelDaum: at least thats how we worked since the old svn days
(09:11:34 AM) gac410: We changed that with git.   We all agreed ages ago    At least I thought we did.
(09:11:51 AM) gac410: master is the "public face"    that's what you get when you pull github
(09:11:56 AM) MichaelDaum: please do use release branches for their own affairs
(09:12:24 AM) MichaelDaum: do not block master because there is a release being spawned off from it some day 
(09:12:31 AM) jast: it makes sense to have a "presentable but not released" branch, e.g. git itself has that
(09:12:54 AM) gac410: Exactly.   master is  "presentable but not released"       
(09:13:03 AM) jast: but each extra level of management is extra work, so we have to decide whether we want to spend that extra time
(09:13:09 AM) jast: more specifically, the release manager :}
(09:13:10 AM) MichaelDaum: again: having too many item branches for core stuff diverts changes too much and devs have all too different code bases that they work on
(09:13:17 AM) gac410: If a merge results in a master that's unusable because it was incomplete,   I intend to revert it.
(09:13:26 AM) jomo entered the room.
(09:13:39 AM) jomo: hiall
(09:13:44 AM) jast: in that case it makes sense to copy another concept from the git dev process: have a branch called 'next' that is less stable
(09:13:53 AM) jast: (not that the exact name matters)
(09:14:11 AM) jast: that gives us somewhere to merge not-quite-complete things to test them in combination, without messing up master
(09:14:29 AM) gac410: Right now we have 4 or 5 item branches ready to merge.      That's going to drop to zero in the next day or so.
(09:14:59 AM) jast: presumably a next branch is overkill right now, but it could come in handy if we ever get more dev activity
(09:15:11 AM) MichaelDaum: right
(09:15:26 AM) gac410: I would like to see us do much fewer patch releases.     But the 2.0 was too big.     and it took 3 releases to stablilze
(09:15:37 AM) MichaelDaum: otherwise you will only catch sideeffects of different item branches on a rather late point in time in the dev cycle
(09:15:49 AM) MichaelDaum: I prefer to get an error as soon as possible
(09:16:40 AM) gac410: Error yes.    Rome is burning around us ... no.     Our merges into master have been really ugly imho.     Configure plugin   was a nightmare IMO
(09:17:12 AM) MichaelDaum: it was this pain that drove development
(09:17:25 AM) gac410: Unicode wasn't pleasant.   but it was a huge fundamental change.
(09:17:26 AM) jast: configure was a nightmare because development happened right inside master
(09:17:37 AM) gac410: exactly.   
(09:18:03 AM) MichaelDaum: if we had hidden configure in an item branch you'd only have delayed this nightmare
(09:18:07 AM) gac410: I'd like to delay merge until the dev. is reasonably comfortable that we *could* release if we had to.  
(09:18:41 AM) MichaelDaum: btw I don't think configure dev was a nightmare
(09:18:43 AM) gac410: And if it merged and was a nightmare  revert and give it more time.   Master should be generally functiona.l 
(09:18:47 AM) jast: George, I think the problem not addressed by that is if the dev in charge of a feature does something everyone else has concerns with... if we only notice it during the final merge, that's a problem
(09:19:16 AM) MichaelDaum: xactly
(09:19:23 AM) jast: sure, you can merge and revert and merge again... but that's not so great either
(09:19:27 AM) gac410: y.  Some of this falls onto all of us to kick the tires on the feature branches.
(09:20:07 AM) jast: if we take up the convention of the next branch, we can play with all the stuff that's cooking before it's ready to be merged to master
(09:20:52 AM) gac410: Anyway.  in hindsight,   I would have preferred branching 02x00   after the initial release,  or maybe after 2.0.1   .... waiting until now was much too long. So mea culpa
(09:21:05 AM) MichaelDaum: collaboration is hindered by item branches. it becomes a one-branch-per-dev thingy ... which I'd rather not encourage. Instead peer review and fixing is much preferable ... which only happens when something goes wrong and another one helps out 
(09:21:50 AM) jast: gac410: it's a learning experience :)
(09:23:11 AM) gac410: I've gotten really really upset at the    "quick checkin and leave"  approach that seems to happen.    "Here's your fix ...  back tomorrow ...   and trunk.foswiki.org is down for the count, unless someone else fixes it .... 
(09:24:23 AM) MichaelDaum: upstet to a certain degree. but thats normal. we always had these kind of situations ... and suddenly lots of progress with it
(09:24:59 AM) gac410: Anyway,  I think there is a middle ground.    Clearly 2.0.3  waited too long to branch.     We should have been open for feature merges in september.
(09:25:22 AM) MichaelDaum: it is okay to make faults. other devs should not be upset by that. instead they should help out.
(09:25:37 AM) gac410: But I still think that incomplete - piecemeal development directly in master is wrong.
(09:26:17 AM) jast: oh, absolutely
(09:26:37 AM) jast: in fact in git they have *two* additional branches, next to master: next and pu
(09:26:37 AM) gac410: If the fault is indeed an honest fault,  sure.      If it's clearly never been tested    Could NOT have been tested  in a live system.    
(09:26:59 AM) jast: pu is bleeding edge, most likely broken. next is kind of a middle ground. master is usable.
(09:28:26 AM) gac410: Anyway,  I'm just bitching about the past.     master is ready,  The backlog of item branches will clear shortly.   
(09:28:45 AM) MichaelDaum: okay
(09:29:13 AM) jast: anyway, I'm not really concerned we'll get into a good groove in time
(09:29:18 AM) jast: *we won't
(09:29:21 AM) gac410: Let's stay on plan for 12/1 freeze,   and as JulianLevens suggested,  we review the merged features at our next meeting,  eve of the freeze,  and make a decision then to delay or proceed
(09:29:26 AM) jast: double negations are hard :)
(09:30:17 AM) JulianLevens: I'll capture the above to create a requirements/problems list so we can discuss it again and hopefully more clearly
(09:30:36 AM) gac410: And evereyone ..... we really need everyone to comment on feature proposals.    
(09:31:22 AM) gac410: Too much stuff gets approved without discussion.     Dead air for 14 days and Done.    
(09:31:44 AM) JulianLevens: How do you keep track of f.o changes, I used to check site changes regularly but ...
(09:32:02 AM) JulianLevens: i.e. I don't notice feature proposals anymore
(09:32:20 AM) gac410: I have "live bookmarks"     and I also subscribe for WebChanges for development,  Tasks, and Support.
(09:33:12 AM) JulianLevens: Subscription is obvious now you mention it. What's a "live bookmark"?
(09:33:26 AM) gac410: Firefox feature.   Puts an RSS feed in to your bookmark
(09:34:12 AM) JulianLevens: Ok, I'd better set something up
(09:34:48 AM) gac410: Anyway.   More practical stuff.     Who merges feature branches.      Should I work on clearing the backlog,   or does each dev merge their own branch?
(09:35:37 AM) jast: it doesn't really matter who pushes the switch as long as dev and RM coordinate
(09:35:47 AM) gac410: Or should we pass a token on IRC so we are not all merging at the same time. ... exactly.
(09:36:31 AM) MichaelDaum: JulianLevens, RSS works out best imho
(09:36:51 AM) gac410: I won't be merging today.    I need to build the  2.0.3 Virtual Machine and get that released,  Upload the extensions,  and work with Michael on announcing 2.0.3
(09:39:19 AM) gac410: I think sourceforge is downloadable now if anyone wants to check out the new release.    
(09:41:16 AM) gac410: So to wrap up.      Everyone okay with.  1) Defer decision on 2.1 freeze until next meeting.    2) Let's let our merge strategy stay as is for now and see if it can work before creating new branches.
(09:42:08 AM) gac410: ie .  1) RM should branch stable sooner.  2) Merge features but try to keep master reasonably releasable 
(09:42:41 AM) jast: works for me
(09:42:59 AM) JulianLevens: +1
(09:43:26 AM) andreli: I'm currently setting up 2.0.3 - thanks gac410
(09:45:13 AM) gac410: BTW  for future releases.   I think we should try to make the   2.x   releases  easier to upgrade in place.    Ie the next time any site should have to re-install /migrage  should be 3.0  
(09:45:59 AM) gac410: I don't think any of the 2.1 proposed features would trigger a major upgrade effort.
(09:46:12 AM) JulianLevens: agreed
(09:48:11 AM) jast: +1
(09:48:15 AM) MichaelDaum: +1
(09:48:32 AM) gac410: btw ... anyone know when cdot will be back?
(09:48:59 AM) MichaelDaum: seen a couple of diving photos on facebook. he seems to have a good time.
(09:49:08 AM) gac410: Ah... vacation.   good.   
(09:49:55 AM) gac410: Thanks everyone.    We'll get this all smoothed out I'm sure.  
(09:50:11 AM) MichaelDaum: of course
(09:50:25 AM) gac410: Michael  I'll start working on a 2.0.3 release topic and we can use that for the basis of the announcement?
(09:56:49 AM) MichaelDaum: perfect
(09:57:13 AM) MichaelDaum: I'll wordpressify it then
(10:06:47 AM) gac410: jast,   Could you also add  the Release02x00 branch into weblate?
(10:07:00 AM) jast: sure