SponsorshipProcess
|
Size: 3086
Comment: document what sponsoring involves
|
Size: 5126
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Sponsorship == | ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">'''Contents'''[[BR]][[TableOfContents]]|| |
| Line 3: | Line 3: |
| The sponsorship process is designed to allow prospective developers to have packages reviewed and uploaded. The review and uploading is performed by an official developer. Sponsorship provides a means of learning about Ubuntu development and lowers the entry barrier for contribution. | = Sponsorship = |
| Line 5: | Line 5: |
| Sponsorship is aimed at dealing with incremental changes to existing packages within Ubuntu. For mentoring on the creation of entirely new packages, please see the [:MOTU/Packages/REVU] process. | The sponsorship process is designed to allow prospective developers to have packages reviewed and uploaded. The review and uploading is performed by a Ubuntu Developer (MOTU) or Ubuntu Core Developer (core-dev). Sponsorship provides a means of learning about Ubuntu development and lowers the entry barrier for contribution. |
| Line 7: | Line 7: |
| == Creating a request == | The process outlined here is aimed at dealing with incremental changes to existing packages within Ubuntu. For mentoring on the creation of entirely new packages, please see the [:MOTU/Packages/REVU] process. |
| Line 9: | Line 9: |
| MartinPitt wrote a little python script that reads a debdiff from stdin or a file, creates a bug report, and assigns it to the appropriate team: |
== Requesting Sponsorship == |
| Line 12: | Line 11: |
| * http://people.ubuntu.com/~pitti/scripts/requestsponsor | * [https://bugs.launchpad.net/ubuntu/+filebug File an Ubuntu bug in Launchpad] or follow up on an existing one and * attach your work * in the case of a patch (using the same upstream version), attach your suggested patch ([:PackagingGuide/Recipes/Debdiff:Howto Debdiff]) * in the case of a upstream version update ([:PackagingGuide/Recipes/PackageUpdate:Howto Package Update]), either * attach the `.diff.gz` file (and link to the new upstream source if necessary) or * link to an upload to [http://help.launchpad.net/PPAQuickStart PPA] or [:REVU]. |
| Line 14: | Line 18: |
| This can only be used to diff changes to existing packages; if its a new package, the package should go through the [:MOTU/Packages/REVU] process. | === New Packages === |
| Line 16: | Line 20: |
| Requirements: | The process for getting NEW packages (packages which are not in Ubuntu at all yet) reviewed is explained at [:UbuntuDevelopment#NewPackages]. |
| Line 18: | Line 22: |
| * You need a deb-src line for the release you upload to (and must be up-to-apt-get-update, of course). * The environment variable DEBEMAIL must be set. * The script currently needs a local MTA. With this script, creating a request is as easy as: {{{ debdiff cupsys_1.2.1-0ubuntu1.dsc cupsys_1.2.1-0ubuntu2.dsc > diff [review diff] requestsponsor diff }}} The script will ask you for your GPG passphrase to sign the bug report. It automatically uses gnome-gpg if it is installed. You can see the currently pending requests at: * https://launchpad.net/people/ubuntu-main-sponsors/+subscribedbugs * https://launchpad.net/people/ubuntu-universe-sponsors/+subscribedbugs |
|
| Line 39: | Line 26: |
| * https://launchpad.net/~ubuntu-main-sponsors * https://launchpad.net/~ubuntu-universe-sponsors |
|
| Line 40: | Line 29: |
| * https://launchpad.net/people/ubuntu-main-sponsors * https://launchpad.net/people/ubuntu-universe-sponsors |
Do not assign a bug to anyone if it needs sponsorship. |
| Line 45: | Line 33: |
| Since Launchpad's email interface currently does not support attachments, requestsponsor puts the diffs inline into the bug report. Therefore it is inconvenient to grab a diff from the web interface. However, if you are subscribed to the team, you get the diff as (gpg-signed) mail. |
You can see the currently pending requests at: * https://launchpad.net/~ubuntu-main-sponsors/+subscribedbugs (or [https://bugs.launchpad.net/ubuntu/+bugs?search=Search&field.subscriber=ubuntu-main-sponsors&field.omit_dupes.used=&field.omit_dupes=on] * https://launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs Or combined at: * http://people.ubuntu.com/~dholbach/sponsoring/ |
| Line 50: | Line 39: |
| Save the email in raw text form, and do: {{{ apt-get source package cd package-* gpg -o - /path/to/saved/email | patch -Elp1 }}} |
The `ubuntu-main-sponsors` team handles sponsorship of packages in the `main` and `restricted` components; the `ubuntu-universe-sponsors` team handles sponsorship of packages in the `universe` and `multiverse` components. To find out which component a source package is in, visit `https://launchpad.net/ubuntu/+source/SOURCE-PACKAGE-NAME` and look at the row for the appropriate release in the "Published versions and upstream associations" table. The component name is in the third column. |
| Line 56: | Line 41: |
| You should check the signature verification result. | |
| Line 58: | Line 42: |
| Check the patch over carefully. If there are problems with it , provide consructive feedback to the bug. A useful - but not authoritative - checklist for sponsoring may be found on Matt Palmers sponsorship checklist : http://people.debian.org/~mpalmer/sponsorship_checklist.html. Checking it well is non-trivial, but you will be responsible for what is uploaded, so its reasonable to check it carefully. |
== Workflow for Review and Sponsorship == |
| Line 61: | Line 44: |
| 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. Do not use the -m or -e flags to dpkg-buildpackage! | If you are processing the universe sponsorship queue, please review the [:MOTU/Sponsorship/SponsorsQueue:Procedure Documentation] or ["UbuntuDevelopment/CodeReviews"] Check the patch over carefully. If there are problems with it, provide constructive feedback to the bug so that it can be revised. A useful checklist for sponsoring may be found on Matt Palmers sponsorship checklist : http://people.debian.org/~mpalmer/sponsorship_checklist.html, though it is neither authoritative nor exhaustive. Exercise your own judgement when reviewing the package. A good review is non-trivial, but you will be responsible for what is uploaded, so be thorough. 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`! To find changes for main that need sponsoring, see the list of bugs: https://launchpad.net/~ubuntu-main-sponsors/+subscribedbugs or http://people.ubuntu.com/~dholbach/sponsoring/ When you start to work on such a bug, assign it to yourself. (If you find a bug on the list above already assigned to someone other than a member of ubuntu-core-dev, that is a mistake. You should probably deassign them and point them at this wiki page.) When you have a solution, i. e. an updated source package which fixes the problem, create a `debdiff` to the current Ubuntu version and attach it to the bug (don't forget to set the "patch" flag for the attachment). When you have finished working on the bug by uploading, set the state to Fix Released as usual, and unsubscribe ubuntu-main-sponsors. If the bug is a sync request, you can finish it by approving the sync. Edit the Description if necessary so that it is a proper sync request. Write a comment into the bug saying that you approve the sync, and subscribe ubuntu-archive. You should unsubscribe ubuntu-main-sponsors at this point. Leave the bug assigned to yourself in case ubuntu-archive have any questions. You will need to be a member of ubuntu-main-sponsors in order to unsubscribe the team from the bug. ---- [:CategoryProcess] |
ContentsBRTableOfContents |
Sponsorship
The sponsorship process is designed to allow prospective developers to have packages reviewed and uploaded. The review and uploading is performed by a Ubuntu Developer (MOTU) or Ubuntu Core Developer (core-dev). Sponsorship provides a means of learning about Ubuntu development and lowers the entry barrier for contribution.
The process outlined here is aimed at dealing with incremental changes to existing packages within Ubuntu. For mentoring on the creation of entirely new packages, please see the [:MOTU/Packages/REVU] process.
Requesting Sponsorship
[https://bugs.launchpad.net/ubuntu/+filebug File an Ubuntu bug in Launchpad] or follow up on an existing one and
- attach your work
in the case of a patch (using the same upstream version), attach your suggested patch ([:PackagingGuide/Recipes/Debdiff:Howto Debdiff])
in the case of a upstream version update ([:PackagingGuide/Recipes/PackageUpdate:Howto Package Update]), either
attach the .diff.gz file (and link to the new upstream source if necessary) or
link to an upload to [http://help.launchpad.net/PPAQuickStart PPA] or [:REVU].
New Packages
The process for getting NEW packages (packages which are not in Ubuntu at all yet) reviewed is explained at [:UbuntuDevelopment#NewPackages].
Sponsoring
Sponsorship is organized by two teams:
Do not assign a bug to anyone if it needs sponsorship.
Any Ubuntu developer who is interested in acting as a sponsor is welcome to apply for membership in the appropriate team.
You can see the currently pending requests at:
https://launchpad.net/~ubuntu-main-sponsors/+subscribedbugs (or [https://bugs.launchpad.net/ubuntu/+bugs?search=Search&field.subscriber=ubuntu-main-sponsors&field.omit_dupes.used=&field.omit_dupes=on]
https://launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs
Or combined at:
The ubuntu-main-sponsors team handles sponsorship of packages in the main and restricted components; the ubuntu-universe-sponsors team handles sponsorship of packages in the universe and multiverse components. To find out which component a source package is in, visit https://launchpad.net/ubuntu/+source/SOURCE-PACKAGE-NAME and look at the row for the appropriate release in the "Published versions and upstream associations" table. The component name is in the third column.
Workflow for Review and Sponsorship
If you are processing the universe sponsorship queue, please review the [:MOTU/Sponsorship/SponsorsQueue:Procedure Documentation] or ["UbuntuDevelopment/CodeReviews"]
Check the patch over carefully. If there are problems with it, provide constructive feedback to the bug so that it can be revised.
A useful checklist for sponsoring may be found on Matt Palmers sponsorship checklist : http://people.debian.org/~mpalmer/sponsorship_checklist.html, though it is neither authoritative nor exhaustive. Exercise your own judgement when reviewing the package. A good review is non-trivial, but you will be responsible for what is uploaded, so be thorough.
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!
To find changes for main that need sponsoring, see the list of bugs:
or
When you start to work on such a bug, assign it to yourself. (If you find a bug on the list above already assigned to someone other than a member of ubuntu-core-dev, that is a mistake. You should probably deassign them and point them at this wiki page.)
When you have a solution, i. e. an updated source package which fixes the problem, create a debdiff to the current Ubuntu version and attach it to the bug (don't forget to set the "patch" flag for the attachment).
When you have finished working on the bug by uploading, set the state to Fix Released as usual, and unsubscribe ubuntu-main-sponsors.
If the bug is a sync request, you can finish it by approving the sync. Edit the Description if necessary so that it is a proper sync request. Write a comment into the bug saying that you approve the sync, and subscribe ubuntu-archive. You should unsubscribe ubuntu-main-sponsors at this point. Leave the bug assigned to yourself in case ubuntu-archive have any questions.
You will need to be a member of ubuntu-main-sponsors in order to unsubscribe the team from the bug.
SponsorshipProcess (last edited 2023-11-30 23:02:43 by bdrung)