On 05/09/2011 06:06 PM, Julien Rioux wrote: > On 09/05/2011 5: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. >> > > That's pretty good option. However if we change to closing these bugs > for yet unreleased versions, we might have to change the default query > to search also for closed bugs. For end users. > Maybe the default query should be like that, anyway. People often use older versions and so can report fixed bugs.
> Another option is to set up custom fields in trac. You can have > checkmark-like fields fixedintrunk and fixedinbranch. You can search > on those individually. > > http://trac.edgewall.org/wiki/TracTicketsCustomFields > This looks complicated. rh
