Technical Release Manager for Samba

[Michael Adam]

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.
Slipping a feature to the next release would hurt much less.
This would require us to have a very strict and simple process
with rules and deadlines for which there can not be exceptions
(of technical nature like feature foobar must make it in..).

> > Now, much more than at times in the past, I think the team is finally at a
> > level of mutual respect where we could cope with someone being elected
> > into a position of leadership, 'in charge', as regards getting us to
> > actually make releases.
> > 
> > To be clear, I see this as being in addition to Karolin continuing in
> > her critical role, the aim would be instead to tackle the things we 
> > specifically excluded from that role:
> >  - championing features
> >  - applying technical insight to difficult choices
> >  - deciding what makes it in and doesn't for a particular release, where there isn't a timely consensus.
> >  - and more generally providing leadership and project direction. 
> > 
> > The idea is to ensure that Karolin can do the mechanics (the 'doing') 
> > with support, confidence and greater ease.  In particular, I'm keen that
> > Karolin has someone to rely on to make the difficult technical choices
> > that will ensure that releases ship on time.
> 
> During the past releases I was typically the one who helped Karolin with
> such decisions. I also went through all the bugs and
> moved blocker bugs to the next release.

This silent background support has been extremely valuable!
But I think Andrew was rather suggesting a a role that acts
in public, as a gate-keeper. One that speaks up in public
towards the team and community, having decision powers for
the case where a consensus can not be reached in a timely manner.

> But I don't think we should have a single person assigned to this,
> who would then have more power than others.

I can understand where Andrew sees the possible desire for such a role,
but I understand and partly share the very general concerns.

> I guess shorter and strict release cycles might already solve the major
> problem.

Indeed! That is a very important point. Let me elaborate on this
a bit, because I was thinking in these lines myself:

- With the current, long release cycles, each release is very
  important, and if a features misses a release it hurts.
  Hence the developer tries to get this feature into the release
  by having the release deferred.

  ==> vicious circle: release cycle get longer and longer.

  In this situation that such a gate-keeper ("in-charge person") in
  front of the technical release management might be useful.

- If we had very short (<=4 months even) and regular release cycles
  with fixed branch and release dates, as indicated above, each release
  would be much less important, ideally not a big deal any more.
  And slipping a feature into the next release would hardly hurt.
  With a very strict and simple set of rules for the release process
  there would hopefully not be a real need any more for deciding
  which features make it in and which don't.

  ==> I.e. this model might remove the need for such an in-charge role
      completely. I am not 100% convinced that we can achieve this
      effect with a 6 months cycle but with <=4 months, I am pretty sure.

> Our review process should make sure master is always able to run in
> production
> with its default settings. This prevents unstable stuff to be
> included/activated.
> 
> Releases based on deadline would then just take what's there and ready.
> 
> I'd propose to try this before we try to add more complex rules to our
> release management.

I think this is wise: Change one thing at a time!
Let's try purely with short and fixed release cycles first.
How short we can get/try depends imho on how much we
can reduce the effort for each single relase and for
the maintenance.

So we would next need to decide on:

- release frequency (6 months? or more radically try 4?)
- fixed release times (e.g. december, april, august)
- lifetime of releases
  (do we stick with current - maintenance - security?)
- release process, e.g.:
  - branch 4 (? or 6?, or ...) weeks before release date
  - stabilize with bugzilla work, no features ported
  - have fixed dates for beta / rc / freeze / release

If this does not work out, we can revisit other options like
the need for an in-charge person.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150505/92f277a3/attachment.pgp>