Richard Heck wrote: > Jurgen liked having the keyword because it made it easier to tell what > bugs had been fixed for the next release. I suppose your suggestion, > closing them with the milestone, probably serves the same purpose. So > I'd be happy to say we just close these bugs now, but make really sure > we set the right milestone.
iirc this was the case up to now and the reason for keyword was that some users complained that its closed as fixed, but not in fact released. i find the whole "fixedinxxx" keywording weird and can't remember any other bug tracking system i used up to now to use this kind of idiom. > So here's a new proposal, modeled on your suggestions: > > 1. Bugs fixed in trunk and branch should be closed, with the milestone > set to the next maintenance release. > > 2. Bugs fixed in trunk with some intention that they should be fixed in > branch should be keyword'ed fixedintrunk, as now, and the milestone > should be set either to the next maintenance release or to 2.0.x. (This > is pretty much as now.) > > 3. Bugs fixed in trunk that we know we will not fix in branch should be > closed, with milestone the next major release (2.1.0, in this case). > > This means that, whenever a bug is fixed in trunk, one of three things > should happen: > > (a) If it should be included in the next maintenance release, then that > milestone should be set and the keyword "fixedintrunk" should be added. > > (b) If it is eligible for branch, but needs testing, etc, then the > milestone 2.0.x should be set and the keyword "fixedintrunk" should be > added. > > (c) If it is not eligible for branch, or if it is decided that it will > not be included in branch (touches too much code, etc), then milestone > 2.1.0 should be set, and the bug should be closed. In this case, > fixedintrunk does NOT need to be set. > > Vincent, is this, in particular, (c), OK with you? We will have all the > same query abilities under this system, so far as I can see, but I'll > have the ability to query the fixed in trunk but not branch bugs, too. > It'll also mean we don't have to do mass bug changes so often. maybe we can close bugs with comment "will be fixed in 2.0.3" so all users do understand. btw we dont have 2.0.0 version in bugtracker, so users can't set up current version properly. pavel
