Summary

The workflow for bugs with patches is rather complicated with regards to what qualifies as a patch and which team to subscribe to which kind of patch. Instead there should be a process that is transparent to contributors where they can add any kind of patch to a bug report and know it will be reviewed.

Rationale

There are far too many bugs with patches that are languishing with no attention and we are losing potential contributions and contributors to Ubuntu.

User stories

Jayna is an upstream developer of a package and has backported a patch that resolves a bug report but does not know nor wants to learn how Debian packaging works. She should be able to add a patch to the bug report, flag the attachment as a patch and know that it will get incorporated into a later version of the package.

Zan has created a patch in the form of a debdiff that resolves a specific bug in the package but is not familiar with the Ubuntu sponsorship process. He also should be able to just add a patch to the bug report and know it will be reviewed.

Gleek is an aspiring Ubuntu Developer and would like to work on fixing bugs in packages provided by Ubuntu. He would like to join a team which is subscribed to all bugs with patches and then can work on creating Ubuntu packages.

Implementation

Community Changes

An Ubuntu reviewers team (name to be determined) shall be created in Launchpad. The team will have the responsibility of reviewing bugs with patches in any form and acting upon them appropriately. An announcement will be made via mailing lists, Ubuntu news sources and blogs to solicit membership in the team. (Daniel Chen)

Documentation Changes

A work flow for the reviewers team will written up, at wiki.ubuntu.com, so new reviewers will know what actions to take with bug reports.

Additionally, documentation will be written indicating that all bugs with patches shall have the reviewers team subscribed to bug reports with patches.

Code Changes

A bug bot shall be written using launchpadlib that aids the bugs with patches workflow. It should perform the following actions:

The bug bot potentially may:

The bug bot should start processing new or recent bug reports, i.e. since the start of Karmic development. As the process and the bug bot are defined and improved then pre-existing bug reports can be added to the review queue.

Investigation should also occur into the utility of Daniel Holbach's sponsoring report and whether something similiar might be of use to the Ubuntu reviewers team.

BoF agenda and discussion

UDS Lucid notes

There is also a considerable backlog of bugs with patches that have not been dealt with / incorporated. How can we go about getting these tested / fixed?

Using the ubuntu reviews team to review the patches

Should there a be a division of teams? or should there just be one team that does everything?

"Social value to a reviews team" as an educational tool

Start with one team that does code reviews in whatever form bzr branch, patches, debdiffs etc

Remove reviewer team from a bug w/ a patch that doesn't apply and then tag the bug as 'patch-needswork'

ACTION:

Review these notes for useful content:

Workflows for different types of patches

Unflag patches when:


CategorySpec

QATeam/Specs/FixingBugsWithPatches (last edited 2010-02-16 08:30:29 by i59F76442)