Proposed changes to workflow bug management

Henrik Nilsen Omma henrik at ubuntu.com
Mon May 26 22:05:40 BST 2008


Scott Kitterman wrote:
> At UDS Intrepid we had a good discussion between a few Ubuntu developers and 
> some people who are active in bugsquad (I recognize that many developers also 
> triage bugs.  The discussion was focused on people who triage, but are not 
> developers.).  I accepted the action to present the issue and proposed 
> solution to the development community for comment (I know bugsquad needs to 
> discuss this too, but I'm probably not the best one to lead that discussion).  
>
> ...
>
> Please discuss.
Thanks for writing this up Scott.

One additional point: With a specific team subscribed to all these bugs 
(workflow-bug-team, say) it becomes easy to see them all together, 
either in the Launchpad listing of subscribed bugs for that team or in 
an external listing.

Brian offered to prepare some suitable scripts to display listings of 
the different categories of workflow bugs in a public location. This 
could be updated every 5 minutes or whatever and such a script could 
also be taught to send useful updates to mailing lists.

Examples of external bug listings:
http://people.ubuntu.com/~ogasawara/hardy-buglist.html
http://people.ubuntu.com/~ubuntu-archive/pending-sru.html

As a result I think we can actually improve the tracking of these 
workflow bugs over what we have today, for developers as well as triagers.

It is not the intention to hide these bugs from anyone who is interested 
but simply to avoid them turning up in default searches for users and 
triagers. If the hidden nature of these bugs is a problem we could have 
an open team as a sub-team of workflow-bug-team to facilitate that on an 
opt-in basis. Duplication should not be a problem because anyone likely 
to want to file such a bug would be an indirect member of 
workflow-bug-team and would see them in searches.

We also considered setting up a separate workflow LP project to track 
these, but that was not favoured because it is useful to associate these 
tasks with Ubuntu packages. Setting all these bugs to Triaged or In 
Progress on filing has also been suggested, but has less support than 
the above proposal. Other constructive proposals are of course welcome :)

Henrik




More information about the ubuntu-devel mailing list