Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
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/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/13/2007 10:49 AM Please respond to Equinox development mailing list To Equinox development mailing list 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 [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007-07-13 11:18 Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/13/2007 08:59 AM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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
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 [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007-07-13 11:18 Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/13/2007 08:59 AM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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 whic
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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/13/2007 08:59 AM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list To Equinox development mailing list 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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
2) Thomas Watson <[EMAIL PROTECTED] com> To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] 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 <[EMAIL PROTECTED] 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
Given bugzilla provides a "clone this bug" link, I think option #2 is the best choice. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Thomas Watson/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2007-07-11 13:42 Please respond to Equinox development mailing list To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev