In IssueZilla, we currently have the keyword regression, which,
according to the definition [1], "can be set if functionality definitely
worked in an older version but is broken in a newer version". For
various reasons detailed below, this keyword alone sometimes is not
sufficient for issue classification.
Specifically, there are, in real, three categories of regression issues
we're interested in:
1.Functionality which is different from the same functionality in a
previous version, but the difference is intentional, since the
respective feature has been overworked, and specified differently than
before.
2.Functionality which is different from the same functionality in a
previous version, and should be fixed. However, the issue is considered
too minor to be a stopper for the next (micro) release.
3.Functionality which is different from the same functionality in a
previous version, and is serious enough to be a stopper for the next
(micro) release.
One could argue that 1. could be clearly "classified" by removing the
"regression" keyword (let aside for the moment different perceptions
about whether the intentional change was a change to the better), and 2.
and 3. could be distinguished by the target milestone field.
However, especially the latter has several disadvantages, as the
information combined into both the "regression" keyword and the "target
milestone" field is prone to becoming wrong over time. In particular
- More often than not, the "regression" keyword is set without setting a
target milestone. This is okay so far, since setting a target
milestone should be done only when there's a commitment to fix an
issue for a particular release. But this means that there's a high
number of regression issues which are effectively unclassified.
- The target milestone of an issue is often very dynamic. That is, as
resources and priorities of development change over time, issue
targets are adjusted. Normally, you would need to take into account
the "regression" keyword for re-targeting, but often enough this does
not happen (as it'd be an additional and seemingly unnecessary
complexity here).
Now regression issues are used as one criterion for the readiness of a
release: All issues from category 2. above should be fixed, else we
cannot release. (Note that sometimes the perception is that all
"regression" issues must be fixed, which is not the case. This
perception is an additional problem with the current handling of the
"regression" keyword).
However, as you've seen, currently the data to decide the number of
issues in category 2. is not really reliable, so the decision on the
release-readiness cannot be reliable, too.
Thus, our proposal:
For the three categories mentioned above, the issues are handled as follows:
1. After adding a justification (i.e. saying that the "regression" is
not considered a regression, but an implementation of a new/changed
concept), the issue is handled as usual. No particular keyword is to be
set. Any already existent regression keyword is to be revoked.
In case that the changed functionality/behaviour is controversial, this
should be discussed in the project and if needed, escalated to the
project lead (next step of escalation would be project leads list).
2. The keyword "regression" is added to the issue (if not already
present), together with a comment stating that the issue is not
considered a blocker for the next release. The target is set to the next
train release (e.g. "OOo 2.x") or "OOo later", depending on the
judgement of the issue's severity. After that, the issue is handled as
usual. In particular, depending on user feedback (e.g. votes), it might
be decided to fix the issue in the next release.
3. The (newly-introduced) keyword "release_blocker" is added to the
issue, the target is set to the next minor release (2.0.<something>).
The keyword definitions would be as follows:
regression:
This keyword can be set if functionality definately worked in an
older version, but doesn't in a newer version. It is very helpful
to give detailed information from which version to which version the
functionality broke. If this issue is considered a blocker for the
next release, the OpenOffice.org team might decide to indicate this
by setting the "release_blocker" keyword.
release_blocker:
This keyword denotes issues which describe a regression, i.e.
functionality which worked in an older version, but is broken in a
newer version. In opposite to the "regression" keyword,
"release_blocker" marks issues which are considered a blocker for
the next maintanance release.
Advantages of this approach:
- The classification of regression issues takes place in one IssueZilla
field only: whether an issue has the "regression", the
"release_blocker", or none of those keywords determines the
category.
(for the nitpickers amongst us: Sure, "no keyword" could also mean "no
regression at all", i.e. indicate a "normal" issue, but this shouldn't
matter for our purpose.)
Thus, the data is less prone to human errors.
- The number of issues flagged with "release_blocker" can be used as
one measure for the readiness of OpenOffice.org for a micro release.
- When re-targeting issues becomes necessary, its clear that
"release_blocker" issues can *not* be re-targeted. Currently, this
decision would require a close examination of the argumentations in
the issue, because it is not clear whether, for instance, a regression
issue targeted to "2.0.4" has this target more intentionally or more
accidentally (and both cases are common :) . With the new keyword,
it's easily clear that changing the target of a "release_blocker"
issue is a no-go.
(And we could easily introduce a query which finds issues which have
been re-targeted wrongly.)
Opinions?
Frank Schönheit, Marc Neumann, Martin Hollmichel
[1] http://www.openoffice.org/issues/describekeywords.cgi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
