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
