On 10/05/2011 12:20 PM, Stephan Witt wrote:
Am 10.05.2011 um 18:10 schrieb Julien Rioux:
On 10/05/2011 11:55 AM, Richard Heck wrote:
On 05/10/2011 11:20 AM, Vincent van Ravesteijn wrote:
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.
We should go through them one by one and decide what to do with them,
then. I'd welcome the help, from anyone. These are the bugs that need
checking:
http://www.lyx.org/trac/query?status=accepted&status=assigned&status=new&status=reopened&order=id&col=id&col=summary&col=milestone&col=status&col=type&col=severity&col=keywords&milestone=1.6.x&milestone=1.6.10&desc=1
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.
That's not how I'd like to record things. Some bugs that get fixed in
trunk we may not know if they will be fixed in branch or not, and at
what point if so, so we will not able to set a specific milestone. See
the other message in this thread about BRANCH_2_0_EXP, or just wait for
my real message about that.
Richard
Sounds like a different status is needed. Right now we have
new
accepted
assigned
closed
reopened
you could have "pending backport" or "in testing" or something.
At work I've introduced "solved"... as intermediate state.
That was not that easy. I had to change trac.ini - easy.
But I want to see it in the timeline too - change of trac code was necessary.
Stephan
In that case we could use your expertise :)
I wouldn't be surprised if this is made easier in a newer version of
trac or by some plugin. This seems like a very clean and common ticket
workflow.
--
Julien
