On 10/05/2011 11:20 AM, Vincent van Ravesteijn wrote:
1. Bugs fixed in trunk and branch should be closed, with the milestone
set to the next maintenance release.
Objection: people don't search closed bugs, and if they do, they probably
end up with so many bugs that might or might not be related.
But we already have this problem, don't we?
That's not a reason to make it worse.
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.)
Objection: Please no bugs with a milestone 2.0.x. First, 2.0.x is not even
a proper release. Second, in the past there seemed not to be a reason
for doing this. Third, when we switch to git, bugs will be fixed in branch
first, then these changes get merged into master automatically.
We have and always have had plenty of bugs with .x milestones. It means:
This bug should be fixed in some maintenance release or other. Try
searching for 1.6.x bugs (which I guess I ought to migrate).
Of course I know we have bugs with a milestone 1.6.x, but I meant that bugs
which are fixed in trunk should not have a 2.0.x milestone. I don't see why
these bugs won't get a milestone 2.0.something or 2.0.something+1.
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.
I don't see the need for the ability to query the fixed in trunk but not
branch bugs. If you just query for bugs with a milestone 2.0.something
and which are not fixedinbranch, you'll end up with a rather small
list. Some of which might be fixedintrunk, but the list is small, so no
need for an explicit query.
Try that search, with 1.6.x as the milestone (unless I've already done
the mass move, in which case try 2.0.x.)
Please don't mass move these bugs to 2.0.x. Most of them don't deserve
such a milestone.
By definition, bugs with a milestone 1.6.x or 2.0.x are not fixed in trunk
because they would get a proper milestone if they are fixed. So, I still
don't know what search you want to be able to do.
If we remove the fixedintrunk keyword whenever a bug gets fixed in
branch, you only have to query for bugs with a milestone 2.0.something
and which have the keyword "fixedintrunk".
Except that there are branch-only bugs that never get fixed in trunk, so
you need both.
A branch-only bug is by definition fixed in trunk right. If it was not fixed
in
trunk it would not have been a branch-only bug. There might be some sort
of regression in branch which didn't occur in trunk, but that's not really a
cornercase to have a special keyword for.
I don't see the need for a change here, though it would be nice to
have the fixedinbranch, fixedintrunk stuff to be a real trac status
rather
than a keyword.
The need is generated by my inability to do queries I need to do.
Again, I don't know what query you want to do.
Vincent
The query that Richard is after is fixedintrunk but not fixedinbranch
This is done by searching for "fixedintrunk -fixedinbranch" in trac 0.12
--
Julien
