Changing milestones on tickets
All, Could somebody tell me the advantage of changing the milestone of tickets that have been closed for more than 10 months ? I'm genuinely curious. P.
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a prior release), and a bug that's marked 'closed' but Unscheduled simply doesn't make sense to me. -Mark On Tue, May 31, 2011 at 9:20 AM, Pierre GM <pgmdevlist@gmail.com> wrote:
All, Could somebody tell me the advantage of changing the milestone of tickets that have been closed for more than 10 months ? I'm genuinely curious. P. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote:
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a prior release), and a bug that's marked 'closed' but Unscheduled simply doesn't make sense to me.
I'm sorry, I'm still failing to see the logic. * You're not sure whether the bug has been actually fixed ? Reopen the ticket, and set it a milestone to the next release. * When a ticket has been closed with a "fixed" resolution, that's it, it's over, regardless of whether it had been scheduled for a specific release at the time it was open. Why changing its milestone to a version that postdate it by, say, a couple of releases? * If you need to find the bugs that have been fixed for 2.0 but not for 1.6, check the time when their ticket was closed. Everything after 05/14/2011 is a good bet...
On Tue, May 31, 2011 at 10:09 AM, Pierre GM <pgmdevlist@gmail.com> wrote:
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote:
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a prior release), and a bug that's marked 'closed' but Unscheduled simply doesn't make sense to me.
I'm sorry, I'm still failing to see the logic. * You're not sure whether the bug has been actually fixed ? Reopen the ticket, and set it a milestone to the next release.
* When a ticket has been closed with a "fixed" resolution, that's it, it's
over, regardless of whether it had been scheduled for a specific release at the time it was open. Why changing its milestone to a version that postdate it by, say, a couple of releases?
Because if a bug is closed, then it's scheduled for the next release by definition. Having bugs closed and unscheduled is an inconsistency in the bug tracker, and adjusting it to a release that it was at least fixed by is putting it closer to consistency than leaving it as unscheduled. Actually tracking down the release it went out in is too much work especially when the comments don't reference that. * If you need to find the bugs that have been fixed for 2.0 but not for 1.6,
check the time when their ticket was closed. Everything after 05/14/2011 is a good bet...
Then what's the point of the Milestone field? I think it should reflect the earliest milestone the bugfix is targeted at, or the earliest milestone it was fixed in. Having it reflect the random setting that happened to be chosen at some time doesn't seem like a good policy to me. At least changing it as I have makes it easier to be more consistent in the future. The date can't be used for such a query, because after the 1.6 branch some fixes went into both 1.6 and 2.0, and some went into just 2.0. I expect this to be the case fairly often, and any closed ticket right now should be marked with milestone 1.6.1 or 2.0 depending on whether it is committed to the 1.6.x branch. -Mark
On 05/31/2011 10:33 AM, Mark Wiebe wrote:
On Tue, May 31, 2011 at 10:09 AM, Pierre GM <pgmdevlist@gmail.com <mailto:pgmdevlist@gmail.com>> wrote:
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote:
> It's so we can see what bugs are actually fixed for 2.0 (as opposed to a prior release), and a bug that's marked 'closed' but Unscheduled simply doesn't make sense to me.
I'm sorry, I'm still failing to see the logic. * You're not sure whether the bug has been actually fixed ? Reopen the ticket, and set it a milestone to the next release.
* When a ticket has been closed with a "fixed" resolution, that's it, it's over, regardless of whether it had been scheduled for a specific release at the time it was open. Why changing its milestone to a version that postdate it by, say, a couple of releases?
Because if a bug is closed, then it's scheduled for the next release by definition. Having bugs closed and unscheduled is an inconsistency in the bug tracker, and adjusting it to a release that it was at least fixed by is putting it closer to consistency than leaving it as unscheduled. Actually tracking down the release it went out in is too much work especially when the comments don't reference that.
* If you need to find the bugs that have been fixed for 2.0 but not for 1.6, check the time when their ticket was closed. Everything after 05/14/2011 is a good bet...
Then what's the point of the Milestone field? I think it should reflect the earliest milestone the bugfix is targeted at, or the earliest milestone it was fixed in. Having it reflect the random setting that happened to be chosen at some time doesn't seem like a good policy to me. At least changing it as I have makes it easier to be more consistent in the future.
The date can't be used for such a query, because after the 1.6 branch some fixes went into both 1.6 and 2.0, and some went into just 2.0. I expect this to be the case fairly often, and any closed ticket right now should be marked with milestone 1.6.1 or 2.0 depending on whether it is committed to the 1.6.x branch.
-Mark
I think using 'milestone' in this way is misleading because it is a field that the bug reporter enters when creating a new ticket. The actual value is usually wishful thinking by the reporter since it rarely appears to be updated. To be fair, most reports appear to be addressed very quickly so that only the difficult ones remain. If you want to use it in that way then I think that it should not be present in the initial ticket. Rather the assigned developer has to assign the milestone. There is probably also a requirement that milestone automatically updates when after each release. Bruce
On May 31, 2011, at 6:06 PM, Bruce Southey wrote:
On 05/31/2011 10:33 AM, Mark Wiebe wrote:
On Tue, May 31, 2011 at 10:09 AM, Pierre GM <pgmdevlist@gmail.com> wrote:
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote:
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a prior release), and a bug that's marked 'closed' but Unscheduled simply doesn't make sense to me.
I'm sorry, I'm still failing to see the logic. * You're not sure whether the bug has been actually fixed ? Reopen the ticket, and set it a milestone to the next release. * When a ticket has been closed with a "fixed" resolution, that's it, it's over, regardless of whether it had been scheduled for a specific release at the time it was open. Why changing its milestone to a version that postdate it by, say, a couple of releases? Because if a bug is closed, then it's scheduled for the next release by definition. Having bugs closed and unscheduled is an inconsistency in the bug tracker, and adjusting it to a release that it was at least fixed by is putting it closer to consistency than leaving it as unscheduled. Actually tracking down the release it went out in is too much work especially when the comments don't reference that.
* If you need to find the bugs that have been fixed for 2.0 but not for 1.6, check the time when their ticket was closed. Everything after 05/14/2011 is a good bet... Then what's the point of the Milestone field? I think it should reflect the earliest milestone the bugfix is targeted at, or the earliest milestone it was fixed in. Having it reflect the random setting that happened to be chosen at some time doesn't seem like a good policy to me. At least changing it as I have makes it easier to be more consistent in the future.
The date can't be used for such a query, because after the 1.6 branch some fixes went into both 1.6 and 2.0, and some went into just 2.0. I expect this to be the case fairly often, and any closed ticket right now should be marked with milestone 1.6.1 or 2.0 depending on whether it is committed to the 1.6.x branch.
-Mark
I think using 'milestone' in this way is misleading because it is a field that the bug reporter enters when creating a new ticket. The actual value is usually wishful thinking by the reporter since it rarely appears to be updated. To be fair, most reports appear to be addressed very quickly so that only the difficult ones remain.
If you want to use it in that way then I think that it should not be present in the initial ticket. Rather the assigned developer has to assign the milestone. There is probably also a requirement that milestone automatically updates when after each release.
I'm OK with that. Mark, you could you add some note on the trac system to remind the person that closes a ticket that s/he needs to update the milestone field ? I find very commendable to strive for consistency, mind you. I'm just not not very comfortable with the idea of modifying old records a posteriori to adjust to new policies...
On Tue, May 31, 2011 at 11:14 AM, Pierre GM <pgmdevlist@gmail.com> wrote:
On May 31, 2011, at 6:06 PM, Bruce Southey wrote:
On Tue, May 31, 2011 at 10:09 AM, Pierre GM <pgmdevlist@gmail.com> wrote:
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote:
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a prior release), and a bug that's marked 'closed' but Unscheduled simply doesn't make sense to me.
I'm sorry, I'm still failing to see the logic. * You're not sure whether the bug has been actually fixed ? Reopen the ticket, and set it a milestone to the next release. * When a ticket has been closed with a "fixed" resolution, that's it, it's over, regardless of whether it had been scheduled for a specific release at the time it was open. Why changing its milestone to a version
Because if a bug is closed, then it's scheduled for the next release by definition. Having bugs closed and unscheduled is an inconsistency in the bug tracker, and adjusting it to a release that it was at least fixed by is
On 05/31/2011 10:33 AM, Mark Wiebe wrote: that postdate it by, say, a couple of releases? putting it closer to consistency than leaving it as unscheduled. Actually tracking down the release it went out in is too much work especially when the comments don't reference that.
* If you need to find the bugs that have been fixed for 2.0 but not for
Then what's the point of the Milestone field? I think it should reflect
1.6, check the time when their ticket was closed. Everything after 05/14/2011 is a good bet... the earliest milestone the bugfix is targeted at, or the earliest milestone it was fixed in. Having it reflect the random setting that happened to be chosen at some time doesn't seem like a good policy to me. At least changing it as I have makes it easier to be more consistent in the future.
The date can't be used for such a query, because after the 1.6 branch
some fixes went into both 1.6 and 2.0, and some went into just 2.0. I expect this to be the case fairly often, and any closed ticket right now should be marked with milestone 1.6.1 or 2.0 depending on whether it is committed to the 1.6.x branch.
-Mark
I think using 'milestone' in this way is misleading because it is a field that the bug reporter enters when creating a new ticket. The actual value is usually wishful thinking by the reporter since it rarely appears to be updated. To be fair, most reports appear to be addressed very quickly so that only the difficult ones remain.
If you want to use it in that way then I think that it should not be present in the initial ticket. Rather the assigned developer has to assign the milestone. There is probably also a requirement that milestone automatically updates when after each release.
I'm OK with that. Mark, you could you add some note on the trac system to remind the person that closes a ticket that s/he needs to update the milestone field ?
I tried to find a place to do this in the trac system, but couldn't find an option like this. There are some validator plugins on the 'trac-hack' website, but they look very primitive and probably wouldn't give something reasonable either. It looks like a trac guru is needed to do something like this.
I find very commendable to strive for consistency, mind you. I'm just not not very comfortable with the idea of modifying old records a posteriori to adjust to new policies...
I was under the impression this already was the policy, and the only reason it wasn't followed and the existing bugs hadn't been updated was the fact that trac has no nice mass-editing functionality. In particular, the 'roadmap' view (a prominent link at the top of the trac) suggests this by showing the bugs fixed for every unfinished milestone, and doing this required that someone insert custom trac markup into the milestones. If there is a bug policy written up somewhere it should probably be linked from main trac wiki page. -Mark
Tue, 31 May 2011 11:44:15 -0500, Mark Wiebe wrote: [clip]
I find very commendable to strive for consistency, mind you. I'm just not not very comfortable with the idea of modifying old records a posteriori to adjust to new policies...
I was under the impression this already was the policy, and the only reason it wasn't followed and the existing bugs hadn't been updated was the fact that trac has no nice mass-editing functionality. In particular, the 'roadmap' view (a prominent link at the top of the trac) suggests this by showing the bugs fixed for every unfinished milestone, and doing this required that someone insert custom trac markup into the milestones. If there is a bug policy written up somewhere it should probably be linked from main trac wiki page.
As far as I know, there simply has been no clear policy to the use of the milestone field. But at least I have the same idea as you here about how it should be used --- tickets should initially go into Unscheduled, and from there moved into a milestone in which they are (or are planned to be) fixed. The reason why so many bugs went into 2.0.0 is that this was the default value earlier, and most of the time the milestone was not updated when the tickets were closed. Anyway, it makes sense to have closed bugs appear under the milestone they were actually fixed in. I see no harm in changing this, and cleaning it up is a good thing. Pauli
Tue, 31 May 2011 11:44:15 -0500, Mark Wiebe wrote: [clip]
I find very commendable to strive for consistency, mind you. I'm just not not very comfortable with the idea of modifying old records a posteriori to adjust to new policies...
I was under the impression this already was the policy, and the only reason it wasn't followed and the existing bugs hadn't been updated was the fact that trac has no nice mass-editing functionality. In particular, the 'roadmap' view (a prominent link at the top of the trac) suggests this by showing the bugs fixed for every unfinished milestone, and doing this required that someone insert custom trac markup into the milestones. If there is a bug policy written up somewhere it should probably be linked from main trac wiki page.
As far as I know, there simply has been no clear policy to the use of the milestone field. But at least I have the same idea as you here about how it should be used --- tickets should initially go into Unscheduled, and from there moved into a milestone in which they are (or are planned to be) fixed.
The reason why so many bugs went into 2.0.0 is that this was the default value earlier, and most of the time the milestone was not updated when the tickets were closed.
Anyway, it makes sense to have closed bugs appear under the milestone they were actually fixed in. I see no harm in changing this, and cleaning it up is a good thing.
It is helpful to have this cleaned up, thanks Mark for taking the time for
On Tue, May 31, 2011 at 7:11 PM, Pauli Virtanen <pav@iki.fi> wrote: this. Ralf
On May 31, 2011, at 9:06 PM, Ralf Gommers wrote:
It is helpful to have this cleaned up, thanks Mark for taking the time for this.
Mind you, I do agree with y'all for the cleaning up. I just had a shock when I received the batch of what I thought were brand new bugs that turned up to have been fixed and closed for months... Anyhow, I got all the answers I needed :)
participants (5)
-
Bruce Southey -
Mark Wiebe -
Pauli Virtanen -
Pierre GM -
Ralf Gommers