Other items to clarify how releases are managed

[Matt Hogstrom <ma...@hogstrom.org>]

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?

Re: Other items to clarify how releases are managed

[Stefan Arentz <st...@gmail.com>]

On 6/11/06, Matt Hogstrom <ma...@hogstrom.org> wrote:

...

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

Hi Matt,

If I had a choice then I would like to see more frequent minor
releases. With only bug fixes and performance improvements. While
keeping the APIs/schemas/tools stable and compatible.

JBoss is a good example of how it should not work. They had more than
300 issues open between 4.0.4 and 4.0.5. That is crazy and it will
take them months to do releases like that. My choices are then to wait
for that release or stay current with JBoss-HEAD and use daily
development releases. Which are unstable.

I think it is fine to have multi-month releases to plan bigger
features and improvements. But for me as a user of the software it is
annoying to wait for a very long time for minor releases. Also many
times those minor fixes are pushed forward because the next big
release is around the corner.

I have of course no idea how the Geronimo team works and what kind of
work is involved to do a release. I can image that apart from
developing it also takes a substantial amount of energy and time to
coordinate the release, run a test kit, etc.

Oh also, take a look at how the Glassfish team is doing releases and
weekly builds. That could also be an interesting model.

 S.

Re: Other items to clarify how releases are managed

["Alan D. Cabrera" <li...@toolazydogs.com>]

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.


Regards,
Alan