[Python-Dev] Version fields [was Re: Goodbye]
nad at acm.org
Fri Sep 24 12:40:10 CEST 2010
In article <4C9C6A6F.6010202 at netwok.org>,
Éric Araujo <merwok at netwok.org> wrote:
> How about revamping the type/versions fields?
> Issue type
> () Feature request (blocked by moratorium: () yes () no)
> () Bug (found in:  2.7  3.1  py3k)
> () Security bug (found in:  2.5  2.6  2.7  3.1  py3k)
> I’m getting tired of explaining the meaning of the versions field again
> and again, let’s put this information directly under the eyes of the bug
I believe there is another separate use case for the versions field that
hasn't been mentioned yet: for issues with "release blocker" priority,
the versions field is often used to identify the upcoming release for
which a resolution is deemed mandatory. However, having a single
versions field is not totally satisfactory for this, particularly when -
as has happened in the recent past - two different release cycles
overlap (say, Python 2.7.x and 3.2.y). A given issue may or may not
apply to both, it may be a "release blocker" for one or both, and, if
both, a fix may be checked-in for one branch but not the other. The
release managers for the two releases may end up using the one priority
field and the one set of version fields for conflicting purposes. It
certainly makes it more difficult to automate a tracking report of
exactly what are the release blocker issues for a specific release.
Besides adding fields to the database for an issue, there are other ways
to handle the ambiguity, of course. The simplest might be to just open
a separate duplicate issue for each additional release blocked.
Presumably that level of detail might only be needed in the endgame of a
release, beta or rc stages. It still places a restriction on the use of
the version field and possibly other fields. In issue workflow
documentation, there should be some description of how "release blocker"
should work, perhaps including something along the lines of "once a
release enters stage <x>, 'release blocker' priority should only be
changed with the approval of the release manager".
nad at acm.org
More information about the Python-Dev