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

[Thomas Watson <tjwatson@xxxxxxxxxx>]

We will bring this topic up for discussion
at next week's architecture call.  Personally I want to use option
#2 but if we are the only team doing this then it will look pretty inconsistent
with the rest of the eclipse teams.

Tom

BJ Hargrave/Austin/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx

07/13/2007 10:49 AM

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

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones

So far, the respondents want #2. Tom was just observing
that #1 has been 
the case in the past. 

Given that (a) bugzilla does not support multiple releases within a single
bug (see CMVC tracks) and (b) bugzilla does have a quick and easy "Clone
This Bug" link, #2 is the most practical and obvious choice. 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788




Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2007-07-13 11:18
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

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







ok.  in theory I support #2 but if everyone else is doing #1 then
there 
may be more merit in consistency.  there is some logic that says things
released in 3.n.x will alos be in 3.n+1.x but that is not always true.
The 
issue may come down to overhead in managing the bugs/process. 

Jeff 



Thomas Watson <tjwatson@xxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
07/13/2007 08:59 AM 

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


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 
cc

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









No we have not done #2 in the past releases.  Searching through 3.2.x
bugs 
for Platform and Equinox you will notice that most (all?) teams seem to
have done #1 for the 3.2.x releases. 

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=Equinox&product=Platform&target_milestone=3.2.1&target_milestone=3.2.2&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=


Tom


Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
07/12/2007 09:19 PM 

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



To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 
cc

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











i thought we were all already doing #2... 

Jeff 

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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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