[Numpy-discussion] Changing milestones on tickets

[Bruce Southey]

On 05/31/2011 10:33 AM, Mark Wiebe wrote:
> On Tue, May 31, 2011 at 10:09 AM, Pierre GM <pgmdevlist at gmail.com 
> <mailto:pgmdevlist at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110531/9e0d8de1/attachment.html>