[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
|
2)
Thomas Watson
<tjwatson@xxxxxx.
com> To
Sent by: equinox-dev@xxxxxxxxxxx
equinox-dev-bounc cc
es@xxxxxxxxxxx
Subject
[equinox-dev] What to do with 3.3.1
07/11/2007 01:42 candidate bugs and milestones
PM
Please respond to
Equinox
development
mailing list
<equinox-dev@ecli
pse.org>
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
