On 09/05/2011 6:27 PM, Richard Heck wrote:
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
I just found this for keyword exclusion.
http://trac.edgewall.org/changeset/8509
it's in trac 0.12
Julien
