[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