Blockers in Bugfix-Releases (Re: [Release Planning 3.6] Samba 3.6.6 on May 31 (was May 24)?)

[Karolin Seeger]

Hi Andrew,

On Fri, Jun 08, 2012 at 08:07:06AM +1000, Andrew Bartlett wrote:
> What can we do to make this less time consuming?  I know security
> releases are a particular pain, but what about normal releases - is
> there anything in that process we could simplify or automate to make
> that simpler?

security releases are more time-consuming, because of the numerous release
branches. The usual release process is automated as far as possible, I
think. Writing the release notes and publishing the news are the most
time-consuming tasks and there is not much space for automation, I think
(yes, some projects can automatically create release notes, but that would
never work for the Samba Team IMHO).
 
> > Additionally, another issue popped up and came across the release
> > planning. But you are aware of that. Very unusual cricumstances.
> > 
> > So you guys want to ship bugfix releases with severe known issues?
> > That might work with more developers working on bugs on a regular basis.
> > Currently, it does not. There are severe bugs that need to be addressed
> > before the next bugfix release. Otherwise, they would never be addressed.
> > IMHO blockers are needed to create a certain pressure.
> 
> Does it really work like that?
> 
> That is, does the threat that the release might be delayed create enough
> pressure that issues are actually addressed, or does it just penalise
> our other users because not addressing it 'just' means that we keep
> delaying releases?

Usually, it helps to raise the issues on the list and issues were not
addressed, because nobody was aware of them (assigning in Bugzilla usually does
not help for some people). I don't think that we penalise other users, but
try to ship stable releases.

> If an issue is severe, then it should deserve attention on it's own, and
> missing the release entirely is our penalty. 
> 
> > Of course a release should not be delayed due to minor issues. If that
> > ever happened, please let me know.
> 
> As per our other discussion, I think we have terrible trouble defining
> minor/major.  For each of us, particularly after spending days chasing
> difficult issue, our particular bug is usually a major issue.

I am trying to ask the developers "hey, what exactly does not work for
users without your patch(es), use children's language". From my point of view,
that's one of the advantages when the release manager is not a developer.
If basic features do not work, it's a major issue. If e.g.a VFS module has a
problem, it's certainly not a major issue.
 
> I would much rather use 'regression' as the definition - that is much
> easier to pin down. 

My problem with the 'regression' is the following. A regression since
when? 3.0? If in 3.6.6 joining of XP clients does not work, it's a
regression compared to 3.0.x, but if it has never worked since 3.6.0, it's
not a regression compared to 3.6.0, but it's definately a major issue from my
point of view 
and I would try to grab one developer to get that fixed before the next
bugfix release.

Does that sound reasonable?

Cheers,
Karolin

-- 
Samba			http://www.samba.org
SerNet			http://www.sernet.de
sambaXP			http://www.sambaxp.org