6 or 4 month releases (was: Re: Technical Release Manager for Samba)

[Andrew Bartlett]

On Thu, 2015-05-07 at 08:33 +0200, Michael Adam wrote:
> On 2015-05-06 at 12:29 +0200, Björn JACKE wrote:
> > On 2015-05-05 at 16:41 +0200 Stefan (metze) Metzmacher sent off:
> > > As written before I think 4 month cycles are too short for us.
> > > 6 would be ok for me.
> > 
> > I think 6 is too short. As mentioned by others, we're not able to support so
> > many releases and we cannot stop support for a release after a year or so.
> 
> Hey, you are actually the first to give an argument for
> saying that 6 (or 4) is too short... :)

> I have already layed out the options for this in another thread
> but noone has commented.

It certainly amused me that suggesting or even discussing 4 or 6 month
releases gained almost no interest until I suggested we delegate
'someone' the power to make sure it actually happened ;-)

> With our current approach of 3 supported releases,
> (current, maintenance, security), we have this:
> 
> 9 months cycle => 27 months lifetime
> 6 months cycle => 18 months lifetime
> 4 months cycle => 12 months lifetime
> 
> Of course on could consider adding two cycles of
> security releases for a release (which arguably
> poses the least efforts), then we'd have:
> 
> 6 months cycle => 24 months lifetime
> 4 months cycle => 16 months lifetime
> 
> Not sure whethe that would be worth it but it might
> be the easiest way to extend the lifetime.

A agree that would be the simplest approach.

> > This will put the work of backports to the distributors.
> > This is not what we want for sure.
> 
> I think that the distributors do already have to do
> the work of maintaining backports to unsupported versions.
> This is nothing new. And I think it would not change much
> to move to shorter cycles. But maybe I am off here.
> Maybe the maintainers of the distributors should comment
> themselves. :)

For Debian, given the kind of policies requiring only fixes for numbed
debian bugs, it ends up being a task of backports regardless of there
being a supported release that could be used.  I have advocated for some
flexibility there, and while you would think that this would mean longer
release 'in development' life would help, actually I think it's the
reverse - ensuring that a release sticks to bug fixes and that new
features are in a new major release (coming soon) would help more.

> And with each single release being not such a bing change,
> we might lower the bar for adopting newer versions,
> possibliy in alternate software channel.
> 
> 
> > [...]
> > Currently we don't even manage to get the releases out in time with our current
> > time plan. The reason for that is that there are "release blocker bugs" which
> > stop Karolin from finishing the release. Most of those bugs in the "release
> > blocker bugs are actually no regressions. There are a lot of feature
> > enhancements, which some developers would like to finish before a new release.
> > This is the main problem I see. Karolin doesn't want to decide on her own which
> > of the bugs listed in the release meta bugs need to be fixed and which not.
> > 
> > I also worked on clearing up the list of bug IDs in those release blocker bugs
> > and I know what pain that is. It is a real pain, becuase there are just numbers
> > listed. No list of bug descriptions or anything. This is the reason why also
> > few people actually actively help to recude the number of blocker bugs, even if
> > Karolin begs for help to bring down that number.
> > 
> > And it is frustrating to see that even when the release date is over since
> > several months, that there still come new "blocking bugs" which are feature
> > enhancements, this is very frustrating for everyone working and helping on
> > getting the new release out.
> 
> Right. This was the main point in bringing up the topic
> of release cycles. (Which is actually a different thread.)
> I have long advertiesed that we should not have any blocker
> bugs at all, essentially.

I agree.  

> The proposal is to stick with strict release schedule.
> No excuses (technically). And the argument is that this
> will be much much easier with shorter release cycles,
> since slipping a release with a pretended blocker bug
> just means a delay of 4 (or maybe 6) months instead of
> 12+ months which hurts much more.
> 
> And each single release should require less work and,
> more importantly, less frustration.

Thank you so much for your thoughts on this!

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba