geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Other items to clarify how releases are managed
Date Sun, 11 Jun 2006 19:22:03 GMT
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.

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

*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)

*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?



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?

Mime
View raw message