Technical Release Manager for Samba

[Jeremy Allison]

On Tue, May 05, 2015 at 12:36:46PM -0700, Jeremy Allison wrote:
> 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.

Oh yeah - one more thing. I don't think we need a separate
"Technical Release Manager". Consensus from the developers
with a healthy dose of user input has always worked better
for us IMHO.

Jeremy.