Technical Release Manager for Samba
obnox at samba.org
Tue May 5 12:13:18 MDT 2015
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
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
> with its default settings. This prevents unstable stuff to be
> 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
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
Size: 198 bytes
Desc: not available
More information about the samba-technical