On 05/09/2011 04:52 PM, Pavel Sanda wrote: > Richard Heck wrote: >> release, so it's more convenient as far as queries go to treat them as >> closed; > personally i'm fine with closing them completely. the whole fixedinbranch > keywording seems useless to me. if bug is closed with "fixed in 2.0.3" why > anybody should not understand whats going on. > 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.
>> (ii) it's impossible to query for bugs fixed in trunk but not in >> branch, because trac simply won't allow that sort of thing, and that is >> something I need to be able to, uh, track. > we did this by setting milestone to the next maintenance release & > fixedintrunk keyword, no? > In this case, there may bugs we want to test more so they may not go into the next release. I guess maybe, in this case, we can set the milestone to 2.0.x and that will also serve the same purpose. 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. Richard
