• Launchpad Entry: review-process-convergence

• Packages affected: all

Summary

This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec.

The current process of reviewing and integrating contributions from outsiders is confusing and needs improvment. This Spec analyses the current state and makes suggestions for improvements.

Release Note

This spec is about the reviewing workflow. It has no (direct) End-User impact.

Rationale

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

Use Cases

We have a vararity of contribution that need to be reviewed before they can be accepted into ubuntu. They include

• - patches (debdiffs) to existing packages - Updates to a new upstream version of an existing package - completely NEW packages - a merged packge from e.g. Debian - Packages, where local ubuntu changes can be dropped (syncs) - Request for backports

Assumptions

Design

An ideal review process has the following features/requirements:

• straightforward process with a small set of ideally easy to use tools.
• Easy tracking of status and involved persons
• NEW Packages need to be approved by 2 reviewers.
• ability to comment, ideally free for everybody to follow up
• Automated reports for helping with reviews, including:
  • debdiff between subsequent uploads
  • comments for subsequent uploads
  • buildlogs / build status (FTBFS, success on what arches)
  • lintian reports
  • for new upstream versions:
    • diff of debian dir (interdiff)
    • otherwise filtered (e.g. excluding translations)

Implementation

Since this draft targets a broad audience, it should be proposed on the MOTU/ubuntu-devel mailing list and/or irc channels to request for additional comments.

For completely NEW packages, it is already common practice to file bugs with the tag 'needs-packaging' [1]. This is made mandatory for every NEW package. In order to get those bugs closed, it is made mandatory to close the malone bug in debian/changelog. Reviewers are required to check this.

In order to track the status and involved persons, the following rules are applied:

• The person working on the package marks himself as assignee
• All interested persons including the reviewers subscribe to the bug
• We use bug statuses to mark the 'voting' of the bug:
  • - Once a sponsoree starts working on a package, he/she sets the status
    • to in progress.
    - triaged means there has been one vote [3] - fix committed means there has been two votes, the 2nd reviewer is
    • uploading the package to the archive.
    - fix released means the package has been accepted to the archive
  • Regular reports about open reviews is posted to the motu mailing list.
  • A (reviewing) team is subscribed to the bug, so they get notified when
    • work is todo. If the package needs more work, the team gets unsubscribed and the bug status is set to 'in progress'. [2]
  • The contributor is free to use REVU, PPAs, or Bzr to create the package.
    • However, in oder to streamline the reviewing process, the bug needs to have attachments in a way that is independent of the way used to create and work on the package. - There needs to be a bug comment providing a 'dget'able URL to the latest
      • version of the package.
      - Debdiffs between subsequent uploads need to be attached to the bug. We
      • will provide tool support for that.
      - Other reports like lintian, buildlogs will be added as attachment to the
      • bug. Tools will eventually be provided for that.
• if the package has an debian ITP bug, a bugwatch is added

[1] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging

[3] Rationale: Triaged is a restricted bug status. You need to be in ubuntu-qa (or something, ubuntu-dev is inherited somehow) in order to set this status.

Code Changes

REVU is changed to provide stable URLs for source packages.

Migration

Currently new packages are reviewed mainly on REVU. Some URLs to packages are manually linked from new package bugs in malone. These will have to be manually updated once the new process is in place. In various places in the wiki links to the REVU pages exist. These will have to be updated together with the content describing the old review process.

We are not aware of other resources pointing to REVU, that would need to get adjusted.

Additionally a mechanism is required to import the existing source packages and comments to the new process. Optionally, old source packages that are no longer actively worked upon can be skipped when migrating.

The change will be announced on the Mailing lists and on irc. Migration of the existing open reviews to the new process is delegated to the persons working on the respective packages.

Outstanding Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

[2]: It is not clear yet, if the ubuntu-universe-sponsors team is to be reused

• for this. Also it needs to be checked, if the bug mails can be sorted out based on needs-packaging tags in an automated manner.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

Meetings notes

• sponsorship process
  • - debdiff (existing package) - new upstream tarball
    • - bugs (links to .dsc) - REVU - somewhere else
    - NEW - merges - syncs - backports
• make a list of review processes Current review methods:
  • bugs
    • - with a debdiff - with a link to .dsc
  • wiki
  • REVU
  • PPA
  • ubuntu archive queue
• evaluate advantages and disadvantages
  • bugs:
    • + has metadata (assignee, comments, ...) - does not have diffs between different uploads + people are used to work through their bugs (as a TODO list) - does not reflect MOTU review process (two sign offs) + add subscribers who are interested in the package + ONE SITE - reporting about reviewing state of the package
  • REVU:
    • + like mentors.debian.net
  • current discussion on how to improve mentors.debian.net

    • - http://lists.debian.org/debian-mentors/2007/10/msg00301.html

  • backports/syncs: build followup on the bugreport
    • - source backports do not have a queue, require core dev even if universe
• come up with a plan what needs to be done to converge all of these

---

CategorySpec