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