[core-workflow] Tracker workflow proposal
Barry Warsaw
barry at python.org
Mon Apr 21 21:00:27 CEST 2014
On Apr 21, 2014, at 02:35 PM, Barry Warsaw wrote:
>Generalizing, it may be in fact that different active versions of Python might
>assign different priorities to the same bug. I'd like to at least keep on the
>table the option to assign a priority per active Python version.
Although it's used somewhat differently in Launchpad (which can track bugs
that affect multiple projects, multiple versions of those projects, and
multiple Ubuntu releases those versions appear in), the concept of a "bug
task" may be informative here.
Bug tasks are a way of providing optional finer grained "applicability" to a
single issue. Let's say you find a bug in project "foo". Generally you just
submit the bug and this creates a single issue.
Now you realize that the bug also affects project "bar". You can open a
second bug task that tracks the status, priority, assignment, and a few other
things, of that bug as it relates to bar. So let's say Alice fixes the bug in
foo; she would only close the foo bug task. A little later, Bob fixes the bug
in bar, at which time the second bug task would be closed.
It's important to note that both bug tasks share the same issue number, and in
fact are part of the same issue. Of course, bug tasks can be added and
deleted as necessary. (E.g. Bob decides that the bug actually doesn't affect
bar.)
In our case, we generally have just one project, but bug tasks may still be an
interesting idea to handle a bug that affects multiple versions of Python.
There could be a bug task for issue 12345 in Python 3.3 assigned to Alice, and
another bug tasks for issue 12345 in Python 3.5 assigned to Bob. This may
also be a way to handle different values of release blocker for different
versions of Python.
Another interesting twist that Launchpad adds is the notion of fix-committed
vs. fix-released. Let's say you walk up to bug 12345 and you see that it is
fix-committed in Python 3.3, but fix-released in Python 3.4. This means that
the bug will not be present in the latest download of the Python 3.4 release
tarball, but it *will* still be present in latest download of the Python 3.3
release tarball. Of course in both cases, the bug will have been fixed in
both hg branches.
Cheers,
-Barry
More information about the core-workflow
mailing list