Talking about "Where We Are At"

[Andrew Sobala <aes gnome org>]

Well, I've been thinking about bugs in the post-2.2.0 timeframe, and I
thought I'd raise some issues here now. Of course the most important
thing to do now is the pre-2.2.0 things Luis raised in his e-mail, but
nevertheless this needs discussing eventually.

* New keyword

We need GNOMEVER2.2, technically as soon as we release, preferably
sooner :-)

* GNOMEVER accumulating

Some bugs are triaged GNOMEVER2.0,GNOMEVER2.1,GNOMEVER2.3. Which is
ridiculous. I propose defining keywords as follows:

GNOMEVER2.0 appears by itself if the bug was reported against version
2.0.x and we don't know if it still occurs in version 2.2. Some bugs,
like Sun multihead bugs, are like this because most people can't test
them.

GNOMEVER2.1 appears by itself if the bug was reported against version
2.1.x and we don't know if it still occurs in version 2.2.

GNOMEVER2.2 appears by itself if the bug is in version 2.2.x and can be
fixed in the 2.2 timeframe (no string/UI/feature freeze breakage).

GNOMEVER2.3 appears by itself for all freeze-breaking bugs that are in
2.2.x.

The rationale for this is that bugs are definitely marked as "Fixed in
2.2" (they get resolved) or "Not fixed in 2.2" (they get a single 2.2 or
2.3 keyword) to help with retriaging old bugs without stepping on each
other's feet.

Of course simply redefining keywords won't fix the bugzilla mess, but
it's a target to work towards. (The definitions are very similar to what
they are today - the important bit is that they are exclusive.)

It would be trivial (um :) to make a script to pull out all the bugs
with more than 1 keyword defined for bug days, and give old bugs some
love at the same time.

What do you think?

* TARGET

In the post-2.0 cycle, we had the equivalent :) of
TARGET2.0.1,TARGET2.0.2,TARGET2.0.3..... while this sort of makes sense,
it means we use loads of keywords for something conceptually simple -
big bugs need fixing. And every "dot dot" release, unfixed bugs in this
list needed their keywords changing.

Priorities would be a simple way to do this. If bugs that should be
fixed in the 2.2 cycle get TARGET2.2.x (judging from the
bug_squad->bugsquad renaming mess, if could cause problems if we rename
TARGET2.2.0->TARGET2.2.x, but with only 40ish bugs we could do it sanely
via the web). Then bugs that should be fixed by "The next release" get
"Urgent" or "Immediate" priorities and we can filter a "Must fix" list
based on that.

Alternatively, if you want to keep with the "Keywords for bugsquad,
Priorities for developers" separation, you could have a TARGET_NEXT
keyword to use in conjunction with TARGET2.2.x to mean the same thing.

* ui-review

FWIW, I just shunted all ui-review bugs to 2.3 because they will break
ui freeze.

-- 
Andrew Sobala <aes gnome org>