On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote: >> 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. >> > 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? Unless someone is using the absolutely latest version of LyX, then the bug for which they are searching may be closed at the previous maintenance release. And that is a whole lot of people, yet we don't see lots of such reports.
>> 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). >> 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). >> > 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. > In this case, I agree: People will get confused if bugs are fixed in a version not to be released for a very long time. >> 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.) > 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. > 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. Having the checkboxes or whatever is fine with me if someone wants to implement it. Or we can upgrade to trac 0.1.12 or whatever, which seems to allow for mixing "yes" and "no" searches. Richard
