Helping get 2.2 out the door

ABI-2-0-0-STABLE continues to be further and further diverged, as
expected, from HEAD. This is simply because HEAD is getting more
advanced, the code has changed drastically, etc. This is not a bad
thing, and it can be viewed as a tribute to the fact that HEAD is making
significant progress. However, again as happens with any branch, this
also means that fewer and fewer fixes can be readily backported from
HEAD to STABLE.
Therefore, it's time for us qa folk to start shifting our focus to
getting 2.2 out the door, and starting all over again (-:

Amongst other things, we could use some milestone triage. This won't
help get any more bugs fixed in any given period of time but it will
help get releases out the door, with the developers focused on getting
the _right_ bugs fixed in time.

I've placed the following milestones in AbiWord and plugins at our
disposal:

2.2 220 This is already in use, but it's for bugs from previous
milestones that really could use fixing before 2.2, and which won't (as
far as we can tell, those assigned and cced on the bug can correct us if
we're wrong) require significant postponement (no more than any one of
most other bugs of the same class).
2.2.x 221 This is for bugs that really could use fixing before 2.2, but
which might entail further delay of the 2.2.0 release, moreso than most
other individual bugs of the same class. It's also for bugs that don't
desperately need to be fixed before 2.2 but which appear that they might
take little enough time and effort that getting it in 2.2.x or even
possibly in 2.2.0 is a distinct possibility.
2.4 240 This is for bugs from prior milestones, INCLUDING 2.2 and 2.2.x,
which don't desperately need to be fixed before 2.2, and probably don't
look to be candidates for 2.2(.x) anyway. Notably those where fixing by
2.2 could easily take a significant amount of postponement, or where
fixing by 2.2.x could cause a sizable change in code in the 2-2-0-STABLE
branch with repercussions in other parts of the program (ie, potential
for regression or new bugs that don't belong in STABLE). Remember
again, no target milestone you set is carved in stone, so don't worry if
it turns out that the fix can be safely backported, then it will be.
Future 1000 Already in use, this used to describe notably bugs that
would require huge amounts of time, effort, intracodebase changes, or
postponement to make any given release. Some of these will end up being
fixed in time for 2.4 (<and there was much rejoicing />), others may not
see the light of day until 3.0 or beyond. This includes rfes as well as
large bugs with lots of legs and/or wings (and yes, that metaphor really
was for code). If it requires fundamental changes to AbiWord and/or its
code, it quite possibly belongs here.

If you aren't sure about a certain bug or don't want to mess with it,
you can of course skip it. If you are troubled by a bug, or those
involved with it raise questions (ie, you mark something for 2.2.x and
someone says it might require a lot of refactoring, so it needs to be
reevaluated), feel free to contact the list. That's what it's here for.

Don't forget that while correlative patterns will naturally emerge
between targets and severities and priorities, these are in fact
independent dimensions. So, for example, a bug of critical severity may
still get bumped back to 2.4 if it requires a lot of time and resources
we don't have. Meanwhile a bug of normal severity might be tacked on to
2.2.x if it would be a relatively self-contained change and not
complicated to implement.
If this still seems incongruous to you, look at it this way. A wise man
(one of the voices in my head) once told me to think of bugzilla as an
n-dimensional lattice, with subspacial resonances defining the spectrums
of individual dimensions.

If anything confuses you (besides my imaginative anecdotes), feel free
to contact the list or me personally (don't shy from irc).

2.2 is gonna be one helluva release, so let's get this cake baked!

Best regards
-MG
Received on Thu Jun 10 03:39:51 2004