Technical Release Manager for Samba

Wed May 6 13:25:16 MDT 2015

On Wed, 2015-05-06 at 12:29 +0200, Björn JACKE wrote:
> 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.

6 months means to provide 2 years of support that we would have 4
branches in support.  That isn't really that different to what we
promise right now, and we could make those as being two in bug-fix
support, and 2 in security support only.  We provide security fixes back
a long way anyway, regardless of our official policies. 

The problem with 9 month releases is more than just the tool issues you
mention below, but that hasn't helped.  The only time we made a 9 month
release is for 4.1, when there were very few features and less interest.
As soon as we started wanting to ship features again, things just
dragged out. 

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

Indeed, and that was why I suggested having a specific point person to
hold the technical side of that role.  Either way, we need to change our
process.  Jeremy commented earlier that consensus is what has driven the
team for so long, and I've certainly argued passionately for consensus
before, but the downside of consensus in this situation is:
 - There is no need for consensus to mark an issue (bug, feature,
regression) as a blocker
 - Consensus has been required to override this, and ship the release
anyway.  
 - Even when that is obtained, it isn't fast, and weeks go by in the
process.

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

I strongly agree.  But I also see this as being why to also have a
shorter release cycle - think sticking to regressions just wont work
unless there is prospect of another release in the foreseeable
future.   

If we don't have that hope, what should we do with all these
non-regressions?  They are important to the submitter and developer, and
neither will be keen to know their pet feature is now another 9 months
away. 

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

Would it be easier if rather thing thinking this as about power, that
instead we think about it as a delegated authority?  You could say
that's all the same thing, but what I'm getting at is that we agree (by
consensus ideally, or consensus and a vote) that for the benefit of
making releases on time, that we defer to the technical judgement of an
experienced team member.  (I'm not nominating myself, but I have thought
on at least one person who I think could do that role well).

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

I totally agree. 

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

I do like this proposal.  It also has the advantage that our users who
report issues can see more clearly when they are expected to be fixed,
rather than it being essentially undocumented that only bugs blocking
the release blocker are likely to get fixed.

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

I still think we need both better tools and a shorter cycle.  Without
that, the new tools will still be abused in the same way - if the
time-frame remains too long, features will still be pushed too early, in
optimistic hope that they are either ready or can be fixed up later.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba