geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Other items to clarify how releases are managed
Date Mon, 12 Jun 2006 01:29:06 GMT
Matt Hogstrom wrote:
> Here is an additional set of questions I originally had in mind when 
> defining what a Version / Release is.  So as not to overload that 
> thread I moved the addtional items here.
> *When do we identify the content of a release?*
> I expect this is the community as a whole that manages this.  However, 
> before someone signs up to manage a release its probably only fair to 
> them to find out what the community is going to want to try and get in 
> so they know what they are signing up to manage.
> What new features / function goes in?  Do we poll the user community 
> periodically and use that input as the basis for content for the next 
> release?
> I'm hoping this would be mostly organic but to set people's 
> expectations most significant thoughts should be know before the 
> release is cast and a schedule is set.  Conversely, are we managing to 
> a time based release and what get's in get's in?  If you're not done 
> and miss the cut off your out of luck until the next release.

We should time box the releases.  I always thought that it was a pipe 
dream to schedule features and bug fixes into a release and expect 
people to show up and fix them.

We work from a prioritized list of bugs and features.  These are 
prioritized by the their impact, if they are bugs, and by the number of 
Jira votes from the community.

> *Who manages a release's content?*
> Does the release manager have sole control over the content of a 
> release?  I think to a certain extent this should be true but that a 
> person signing up for a release knows what content is proposed so it 
> is less dynamic than we've done in the past.  If the person managing 
> the release doesn't have say so in this area they're likely to get 
> very tired, pop a cork, and send nasty notes to the dev list.  I've 
> heard of this happening.

The release manager (RM) who is the steward of the communities wishes.  
The RM reviews every issue for accuracy of classifications, e.g. bug, 
blocker, etc.  If the reporter has an issue with the classification then 
the issue can be brought before the community.  The RM is responsible 
for deciding which issues will make it into a time boxed release and 
which are too risky.  If the developer thinks that an issue is not too 
risky or that a release should be delayed, the issue can be brought 
before the community.

> *What is a "blocker" bug?*
> How do we determine if a bug is a blocker and should delay a release?  
> One way is to classify the bugs in tiers of seriousness like:
> Data Corruption Possible
> Application Deployment Failure
> - Can't it be bypassed or not
> Error messages not useful
> New feature not working (can it be supressed until the next release)

Using the policy that I outlined in the other thread obviates the need 
to hold up *any* bug fix.
> *What is a feature versus an improvement?*
> This will always be a tricky one.  Aaron had a few items he wanted to 
> add to 1.1 which made perfect sense from improving the user 
> experience.  One might say they were bug fixes that were correcting 
> improper messages and the like and someone else might say they were 
> new features.  How do we handle the resolution of those types of 
> issues?  Does the release manager get a significant binding vote?

Why bother to make this distinction?  Using the policy that I outlined 
in the other thread obviates the need for such subjective distinctions.

> To be honest, my big concern over feature / bug debates is that we 
> seem to be on a multi-month release cycle.  At that rate and pace it 
> will be difficult to fix bugs / performance issues without making 
> users wait a very long time in between stable drops.  Do others have 
> suggestions on how to handle this?

Disciplined time boxing.


View raw message