[core-workflow] Tracker workflow proposal
R. David Murray
rdmurray at bitdance.com
Mon Apr 21 22:29:14 CEST 2014
On Mon, 21 Apr 2014 15:00:27 -0400, Barry Warsaw <barry at python.org> wrote:
> 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.)
I have to say that as an outsider looking in, this was *totally*
confusing. I signed up to see 'python' bugs, and most of the traffic
on the tickets seemed to be about changes to things that looked like
other tickets but I guess were bug tasks.
Our case would be more straightforward...but I'm still not sure that
the extra complexity would be worth it.
--David
More information about the core-workflow
mailing list