>
>  >>
> > 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
>

I would propose to remove the milestone by default (or choose some
threshold: all bugs < 6500 or so). Only exceptions might get
forwarded to 2.0.x. Most of the 1.6.x bugs are untouched for a long time,
so nobody seems to be willing to work on them, and nobody thinks
they are really urgent.


> 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.
>
I usually set the milestone to the next minor release if a bug was present
in branch as well. It was up to Juergen whether he resets the milestone,
or leaves the bug there until he created the milestone for the next next
minor release.

However, this sounds more like code management than bug management.
The most important thing is that you keep track of which code goes in
which branch at which time. Remember there are also fixes and new features
that are not connected to any bug.

The whole milestone stuff for fixed bugs is redundant and only interesting
to keep track when a bug can be closed.


Maybe we can set up git such that when a fix for a bug gets merged into
the next level of stability, it automatically updates the milestone. :).


>From the top of my head in a non-existing scripting language:

=> git notes add 393aa28v -m "Trac-id: #7430"
=> add a post-receive hook
     if ((git notes show #393aa28) contains Trac-id) {
         if (target-branch == BRANCH_2_0_X) {
              b = trac_db.get_next_minor_release();
              trac-db.set-milestone(id, b).
         }
     }

There are so many nice things to do :D.

Vincent

Reply via email to