[Releasing] rethinking the branching scheme

[John Layt]

On Wednesday 19 Feb 2014 15:09:03 Oswald Buddenhagen wrote:
> On Wed, Feb 19, 2014 at 01:23:27PM +0100, Sergio Ahumada wrote:

> > regardless of the topic under discussion .. I think the problem for
> > this disaster^Wrelease was mostly the lack of communication.
> 
> the need for an enormous amount of communication is one of the problems
> of the current system. it worked as long as you did everything yourself
> and were willing to apply all necessary workarounds (though i'm sure you
> didn't really enjoy the number of steps involved, and you made some
> mistakes that would have had no chance if the process was less
> convoluted).
> 
> > I am still waiting for the email that announces that 'stable' and
> > 'dev' are blocked and for how long just to give one example.
> 
> while we historically sent out these mails, they aren't strictly
> necessary ... things were announced in advance, and the reasonable
> expectation is "as planned, until further notice". that it's not
> sufficient to just fire off a single mail "things went as planned,
> please use for/5.3 for important fixes now" to have everything covered,
> is part of the problem.

Actually, I found the communication around this release schedule fairly good, 
just the actual branch freezes didn't seem to be communicated as well.  While 
I don't think anyone can reasonably claim that they didn't know the plan for 
the freeze, I suspect there are a few people who don't check the development 
list as often as they should, or maybe are not subscribed at all.  It does 
take a while to get used to the rhythm and disciplines of timed releases with 
strict freeze dates rather than the old when-its-ready feature releases.  
Email can also be an ineffective way to update people on things happening in 
1-2 hours time, and the dev list is high enough volume for things to maybe get 
missed.

So here's two suggestion to improve that side of things:

1) Have a new email list development-announce that all Gerrit accounts are 
automatically subscribed to and that they cannot unsubscribe from.  Send all 
release schedule and freeze notices and reminders to this list, as well as 
planned outages to Gerrit and Jira.  Keep it low volume so as not to annoy but 
to grab attention when it does.

2) Gerrit is the one place we can guarantee everyone will be looking so have a 
message area displayed at the top of every page for posting status notices.  
One month out from freeze, post a message with the UTC time the repos will be 
frozen so that no-one can claim to have missed it, especially if they try 
merge commits on the day :-)  When frozen, change the message and give an 
estimate on when they will be unfrozen, and keep it updated as things 
progress.

I have nothing much to add to the branching scheme itself, other than liking 
the simplicity of the dev/stable/release naming.  What I do find strange is 
the need some people have expressed for dev to be kept open for merging their 
changes into all the time, I really can't see why anyone would need to merge 
during a 2-5 day freeze window when you can still push for review, so why the 
urgency to have it physically merged when everyone else will be shifting focus 
to stable?  Have a little patience :-)

If we can get the manpower / buildpower, then more frequent bugfix releases 
would be nice, but that needs better automation of the release and qa process, 
and perhaps a stricter rule on what is allowed to be merged to stable so the 
diffs are not as large and the testing required can be reduced.

Cheers!

John.