Technical Release Manager for Samba

[Stefan (metze) Metzmacher]

Hi Andrew,

> 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.

> 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.

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

> Note, this specifically would not be a general 'community evangelist' role, 
> and any candidate would specifically need a strong technical background 
> to be successful.
> 
> (I do think it is important that we establish some kind of decision
> making power, but restricted to matters of the release (and the features
> enabled and default behaviours therein), issues around what is
> acceptable for development in master would continue as-is, but hopefully
> with some strong and respected guidance. )

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

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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150505/76e79551/attachment.pgp>