Release early, Release often

[Andrew Bartlett]

On Sun, 2015-04-26 at 07:21 -0500, Scott Lovenberg wrote:
> On Sat, Apr 25, 2015 at 4:06 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> [snip]
> >
> > The position I have is that, now that we are past the disruptive time of
> > the 4.0 merge, we just shouldn't be waiting for features.  We should
> > instead have a much more 'linux-kernel' release schedule, making new,
> > production releases on a time-frame measured in months, not years.
> >
> > We need a much higher release velocity to give our users and customers
> > confidence that even if a feature is on the Roadmap as under active
> > development, or that if a feature is in master, that it will soon be
> > in a release.
> >
> 
> How would it be decided which features and bug fixes make it into a
> release?  

It would be features that are present at the date the release branch is
made, presumably 6 weeks before the 4-monthly release window (as a
starting point for discussion). 

> Would there be a merge window as the kernel has and anything
> merged then will be in the RC/release, or would whatever is ready
> and/or non-breaking when it's time to cut a release (after all
> blockers are resolved)?   Also, I assume that the current policy for
> critical and non-critical security issues will remain unchanged.

My hope is that we would stop assigning blocker status to features, but
only to regressions.  We over-used the blocking bug as a way to get
things to the attention of the release manager, that we wanted in a
release.  That is, not all the things with blocker bugs against them
were regressions.  

That said, we should maintain a different, but related bug tracker for
bug fixes pending backport. 

> I do like this idea as I get enough grief from people that it's not
> nearly unheard of for a Samba minor release to break something due to
> the amount of changes that are in a release. It has gotten much better
> lately, but it takes a while for users to unlearn patterns.

Hopefully if we make releases more often, then larger changes don't need
to be backported, but there will always some be pressure due to
organisations getting scared to move between major version numbers. 

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