Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I think option 2) is generally the way
to go.  On rare occasions I have used option 1) if I release a fix
into both streams at once, but if there is any time difference between
the fixes being released (and usually there is), having a separate bug
report per stream makes the most sense to me.

John

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

07/11/2007 01:42 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[equinox-dev] What to do with 3.3.1 candidate bugs and milestones

Each major release the same thing happens.  We start fixing bugs in
HEAD for the next major release but find a few fixes that we would like
to also release into a maintenance release.  Then we have to decide
what to do with the status of the original bug report which was used to
release the fix into HEAD.  I have seen this handled in two ways.

1) Leave the bug open and mark the milestone to the next maintenance release
milestone (e.g. 3.3.1) and make a comment in the bug report stating the
fix was released to HEAD.  If/When the fix gets approved and released
for the maintenance release then the bug is marked as fixed; otherwise
we make a note that the fix is not going to be included in the maintenance
release and the milestone is updated to major milestone the fix was included
and marked as fixed. 

2) Resolve the bug report and mark the milestone appropriate for the next
major release (e.g. 3.4 M1) and open a separate bug with a proper milestone
for the maintenance release (e.g. 3.3.1). 

For the past couple of releases the Equinox team has used option #1 but
this has a few drawbacks.  First of all, it gives inaccurate search
results when querying bugzilla for the list of bug fixes for the next release
milestone because code was released into the milestone but the bug is left
open and marked for a maintenance stream.  Also I find it generally
confusing that the bug status does not reflect the fixed state of the bug
until we can get approval and actually release the bug into the maintenance
stream. 

The second approach has its advantages because it accurately reflects the
state of the bug for a particular stream and makes for more accurate search
results for fixed bugs and milestones.  But there is a risk that the
open bug against the maintenance stream will not get approved for release
and then we would have to resolve the bug as wontfix (or something).  I'm
not sure that is really a problem because at least the reason why the fix
is not in the maintenance stream is recorded.  Another disadvantage
is that the bugs will look like duplicates which could cause confusion.

What are other committers preferences?  How is this handled on other
teams?  Is there a standard Eclipse way to handle this?

Tom
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev