On 05/09/2011 05:15 PM, Pavel Sanda wrote: > 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. > Something like that would be fine with me: Instead of just "Fixed for branch at r29876"; add "Due out in 2.0.1". Or else tell people to look at the milestone.
> btw we dont have 2.0.0 version in bugtracker, so users can't set up > current version properly. > I've seen to this. rh
