FixingBugsWithPatches

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:

  • subscribe the reviewers team to bugs with attachments flagged as patches
  • subscribe the reviewers team to bugs with bazaar branches attached to them
    • might just subscribe the appropriate sponsor's team and bypass the reviewers team

The bug bot potentially may:

  • unflag patch attachments that are not really patches
  • flag attachments that really are patches and subscribe the reviewers team

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

  • there is no team in Launchpad for the ubuntu reviews team

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

  • ubuntu reviews team versus sponsorship teams

"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:

  • Get in touch with Daniel Chen about Reviewers Team (James Westby)
    • in the event there is no Launchpad team for ubuntu code reviewers create one (James Westby)

  • Document process at https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews (Daniel Holbach)

  • Write a script to subscribe the team to new bugs with patches (Brian Murray)
  • Document new tag "patch-needswork" and "patch-refused" and add to the list and official bug tags (Brian Murray)
  • Blog about progress every month (Daniel+Brian)
  • Keep stats on quantity of bugs with patches and make a graph (Brian Murray)
  • Document process for bugs w/ branches to request a merge proposal for the reviewers team to review (Brian Murray)
    • possibly also have the script that watches for patches watch for branches w/o merge proposals
  • file a bug that there is not an active reviews page for ubuntu (James Westby)

Review these notes for useful content:

Workflows for different types of patches

  • bugs with diffs
    • tagging patches as patch-verified
      • people who can verify a patch should be able to create a debdiff
    • possibly create a team of people that would convert patches into debdiffs
      • jamesw - subscribe the appropriate sponsors team to the bugs with patches (maybe identify them with a tag - 'patch'? and some tagged as 'debdiff')
        • - perhaps only bugs with a certain priority? High or Criticial?
      • if the volume becomes too large a team could be created
  • bugs with debdiffs
    • clear workflow with the sponsorship queue
    • subscribe sponsorship team to bugs with debdiffs?
    • outdated debdiffs are certainly vaild for subscribing the sponsors team
  • bugs with bzr branches
    • subscribe the sponsorship queue to these bug reports
    • premature to describe another process (merge requests) if the process might change

Unflag patches when:

  • not a patch
  • does not fix the problem

CategorySpec

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