Hi Frank, *
first of all: I support this idea, as it would hopefully help to
- reduce discussions about fixing a regression or not, when we are close
to a release
- make it more easy to identifiy blocking issues (and make shure that
they are really fixed and QA'ed before release)
- have an identifier, what issues could be retargeted and what issues
must not
.. some comments inline ...
Frank Schönheit schrieb:
.....
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).
As Christian already said, this doesn't work well at the moment. But
this needs to be discussed elsewhere.
Juste a note: with "discussed in the project" and "escalated to the
project lead" we speak about the project, that is the issue owner (e.g.
sw for a Word Processor Issue). Escalation to the project leads list
might be difficult, if the concerns are brought in by users and the
project lead is not responsive. Users are normally not subscribed to the
project leads list .. so we have no way to escalate.
I'd say, we should name the qa project (or the council'S communit
representative) as a possible way for escalation (if responsible project
lead is not responsive).
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.
I would separate the "release_blocker" keyword from regression. We could
have blockers that are no regressions (e.g. security issues).
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
