Contents

  1. Workflow
    1. Sponsoring
      1. Sponsors Team
      2. Patch Pilots
    2. Keeping the Sponsoring Queue manageable
      1. Bugs fixing small details
      2. Not suitable for the current release period
      3. Changes needed, but no response from submitter
    3. Prior to sponsoring
  2. Review
    1. Working with Merge Proposals
    2. Packages maintained in Launchpad's Code Hosting
    3. Kernel patches
    4. Being picky
    5. Credits
  3. References
  4. Review Tips
    1. Source
    2. Build
    3. Forwarding Patches Upstream
    4. Guideline Criteria for New Package Inclusion

Sponsoring Statistics

Workflow

Sponsoring

Sponsors Team

Members of the ~ubuntu-sponsors team

To get the queue of merge proposals / patches under control, if the patch was deemed not to be good enough yet,

The preferred way of closing bugs is ClosingBugsFromChangelog.

Patch Pilots

In addition to the Sponsor team is the Ubuntu Patch Pilots team. Each Patch Pilot has a dedicated time each month to be available on IRC in #ubuntu-devel so you can talk to them and discuss issues there; the current pilot on call is listed in the topic in #ubuntu-devel.

Information on how to chat with a Patch Pilot or how to become one can be found in the Ubuntu Patch Pilots program documentation

Keeping the Sponsoring Queue manageable

To avoid making the bug lists too huge, the following measures might be useful.

Bugs fixing small details

  1. Ask the contributor to forward the patch upstream.

  2. Open an empty upstream bug task.
  3. Mark the Ubuntu task as 'Fix Committed'.

  4. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as "Work in Progress". (Be sure to tell the contributor to reverse the process)

Not suitable for the current release period

  1. Let the contributor know that the patch is not suitable for the current release period.

  2. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as "Work in Progress". (Be sure to tell the contributor to reverse the process)

  3. Subscribe yourself to the bug report (this ensures it shows up in the following url)
  4. Milestone the bug to 'later'.

  5. Visit https://bugs.launchpad.net/people/+me/+bugs/?field.milestone%3Alist=196 once the new release opens and upload the fix.

Changes needed, but no response from submitter

If you come across sponsoring items which need fixing from the submitter, and we haven't heard anything back in a while, you might want to unsubscribe ubuntu-sponsors or mark the merge proposal as 'Work in Progress' and inform the submitter about it.

Prior to sponsoring

For patch authors who can't upload yet we have the SponsorshipProcess. Unfortunately, there's also a big list of bugs with patches that are not following the process. Likely, because they are not aware of it.

The ReviewersTeam will

As a member of this team you are not expected to be an uploader, but to know the process and to be able to test the patch for suitability.

The common workflow is:

  1. make sure the attached patch is a genuine patch, if it isn't:
    1. let the author know in a bug comment
    2. remove the patch flag

  2. if there's an upstream bug linked and in the upstream bug a conversation about the fix is going on, add the tag patch-needswork

  3. check if the fix is in a code branch, make sure the branch is linked and a proposal for merging has been made
  4. if you can't upload

    1. make use of the SponsorshipProcess and subscribe ubuntu-sponsors

Review

As a reviewer you should make sure the following rules are observed:

Working with Merge Proposals

The Ubuntu Distributed Development documentation has good information if you want to

Packages maintained in Launchpad's Code Hosting

Special attention is required if packages are maintained on Launchpad's Code Hosting. You might run into a message like this, when getting the source package: 

$ apt-get source ubuntu-artwork
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'ubuntu-artwork' packaging is maintained in the 'Bzr' version control system at:
https://code.launchpad.net/~ubuntu-art-pkg/ubuntu-artwork/ubuntu
Please use:
bzr get https://code.launchpad.net/~ubuntu-art-pkg/ubuntu-artwork/ubuntu
to retrieve the latest (possible unreleased) updates to the package.
[...]
$

Please note that this case differs from packages that merely make use of DistributedDevelopment. The history of almost all source packages is mirrored in lp:ubuntu/<package> branches. In this specific case in addition to the mirrored branch of upload history, the upstream source is maintained in Launchpad too.

In these cases, please either:

Kernel patches

If you encounter a patch for the linux kernel, you should generally follow the kernel process for bugs. Generally the patch should be forwarded upstream first and can be included once it has landed there. There is good documentation on test-building as well. If you need any help, join #ubuntu-kernel talk to the people there.

Being picky

It makes sense to be picky in the following cases:

It makes NO sense to be picky in the following cases:

In the cases of small mistakes, please

This will keep the process lightweight and fast, but still train new contributors.

Credits

To upload, do a source only build of the package as normal, but make sure that your name is not in the Maintainer: or Changed-By: headers of the changes file. The easiest way to do this is to use the -k option to dpkg-buildpackage or debsign to sign it with your key (but leave it otherwise unchanged). Do not use the -m or -e flags to dpkg-buildpackage!

References

Review Tips

Source

Build

Forwarding Patches Upstream

Guideline Criteria for New Package Inclusion

A package NEW to Ubuntu should be actively maintained upstream and receive security- and bugfixes regularly. If this can't be fulfilled, the package maintainer is 100% responsible for the above. Since Ubuntu package maintenance is by team, this is a team responsibility. If individuals have a deep interest in a particular package that they want to provide dedicated maintenance to, they should get the package in Debian and maintain it there (issues can still be fixed in Ubuntu as needed, but doing the bulk of the maintenance work in Debian suites both projects better). In every development cycle there are far more new packages for review than can be properly reviewed and included. Redirecting people to Debian to get new packages into Debian and Ubuntu is a great way to reduce this overload and give back to Ubuntu's primary upstream.

Maintainers are encouraged to check if work is already being done by Debian maintainers at (http://www.debian.org/devel/wnpp/requested and http://www.debian.org/devel/wnpp/being_packaged). Following up on existing bug reports with a link to your source package. (Also check out the Debian Mentoring FAQ to find out how to get your package included in Debian.)

MUST, as used above, indicates that a package not meeting that test is not appropriate for inclusion in the archive.

SHOULD, as used above, indicates that the reviewer should explicitly agree to the variance from the condition prior to advocating the package for inclusion in the archive.

Go back to UbuntuDevelopment.
CategoryProcess

UbuntuDevelopment/CodeReviews (last edited 2023-08-21 12:01:15 by kewisch)