Technical Release Manager for Samba

[Björn JACKE]

On 2015-05-05 at 16:41 +0200 Stefan (metze) Metzmacher sent off:
> As written before I think 4 month cycles are too short for us.
> 6 would be ok for me.

I think 6 is too short. As mentioned by others, we're not able to support so
many releases and we cannot stop support for a release after a year or so. This
will put the work of backports to the distributors. This is not what we want
for sure.
	


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

Currently we don't even manage to get the releases out in time with our current
time plan. The reason for that is that there are "release blocker bugs" which
stop Karolin from finishing the release. Most of those bugs in the "release
blocker bugs are actually no regressions. There are a lot of feature
enhancements, which some developers would like to finish before a new release.
This is the main problem I see. Karolin doesn't want to decide on her own which
of the bugs listed in the release meta bugs need to be fixed and which not.

I also worked on clearing up the list of bug IDs in those release blocker bugs
and I know what pain that is. It is a real pain, becuase there are just numbers
listed. No list of bug descriptions or anything. This is the reason why also
few people actually actively help to recude the number of blocker bugs, even if
Karolin begs for help to bring down that number.

And it is frustrating to see that even when the release date is over since
several months, that there still come new "blocking bugs" which are feature
enhancements, this is very frustrating for everyone working and helping on
getting the new release out.


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

+1. Instead I think we should do something, so that Karolin is actually able to
make releases in time. The release blocker meta bug reports do not help at all.
They are being misused to delay releases in order to get more features in.

Weeks ago I already proposed to Karolin to change the handling of blocking bugs
for releases: Bugzilla already knows all the information on bugs needed to list
the blocking bugs for a release:

Product: Samba 4.1 or later
Severity: regression (yes, nothing else!)
Target Milestone: the next Release
Status: unconfirmed,new,assined,reopened,needinfo

This way there we actually get good list and an overview of bugs that need to
be fixed for the next release because they are regressions. No chance for any
body to smuggle in feature enhancements. And by definition only a regression
bug can delay a release.

See this bugzilla URL:

https://bugzilla.samba.org/buglist.cgi?bug_severity=regression&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=NEEDINFO&list_id=2879&query_format=advanced&target_milestone=4.3

This gives back a well defined list and a good overview of blocking bugs.

Compare that with the chaos of non-descriptive bug numbers like in the current
4.3 release blocker bug https://bugzilla.samba.org/show_bug.cgi?id=10695 - have
fun to browse the list of "blockers" there. This is simply a pita.

Let's improve that and actually strictly stick to our current release cycles. I
think we'll all be much happier then already.

Björn
-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
  ☎ +49-551-370000-0, ℻ +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150506/f0cb15e8/attachment.pgp>