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

[Karolin Seeger]

On Sat, Jun 09, 2012 at 04:39:46PM +0200, Karolin Seeger wrote:
> 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
						
s/definately/definitely/
											
> 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
> 
> 

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