Technical Release Manager for Samba

[Jeremy Allison]

On Tue, May 05, 2015 at 08:41:10PM +0200, Volker Lendecke wrote:
> On Tue, May 05, 2015 at 08:13:18PM +0200, Michael Adam wrote:
> > On 2015-05-05 at 16:41 +0200, Stefan (metze) Metzmacher wrote:
> > > > In thinking about 4 month release cycles, I've been concerned that our
> > > > current 'nobody is in charge'/consensus mode of operation may make practical
> > > > operation difficult.  
> > > 
> > > As written before I think 4 month cycles are too short for us.
> > > 6 would be ok for me.
> > 
> > Is this a gut feeling or is there reasoning behind this?
> > 
> > For me, this really depends on how much we would be able to
> > slim down the release and maintenance work:
> > 
> > I do certainly see the appeal for having very short release
> > cycles. By having releases very frequently (<= 4 months), each
> > single one becomes much less important, and more easy to do.
> 
> We need to revisit our support statement then. With 4 months, a single
> release is only supported for a year. This might be pretty short for some.

Six months is clearly too short. My preference - aim for 6 months,
and don't be too upset if it ends up at 9.

We have to step back and ask who the releases are for ?

OEMs usually have their own release tree - they use our
release numbers as a guide, but are willing and able to
use git trees and back-port specific patches for their
customers.

Linux distros IMHO are the biggest consumers of our release
streams, so I'd like to hear what would work best for
them.

Cheers,

	Jeremy.