SponsorshipProcess
|
Size: 6259
Comment:
|
Size: 6456
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;"><<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: |
| 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. | The sponsorship process is designed to allow prospective developers to have packages reviewed and uploaded. 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 [[UbuntuDevelopment/NewPackages]] 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 | To make use of Ubuntu merge proposals, follow these easy steps: * [[http://packaging.ubuntu.com/html/getting-set-up.html|set up the tools]] * [[http://packaging.ubuntu.com/html/udd-intro.html|get the source]] * [[http://packaging.ubuntu.com/html/fixing-a-bug.html#work-on-a-fix|work on the package]] * [[DistributedDevelopment/Documentation/SeekingSponsorship|seek sponsorship]] |
| Line 14: | Line 17: |
| 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. | |
| Line 16: | Line 18: |
| [Martin reports that this script needs some improvement, as it is a bit out of date (July 25, 2007).] | The traditional process involves: |
| Line 18: | Line 20: |
| Requirements: | * [[https://bugs.launchpad.net/ubuntu/+filebug|File an Ubuntu bug in Launchpad]] or follow up on an existing one. If you think this might be a security update, please review the security team's "[[SecurityTeam/UpdateProcedures#Issues%20that%20warrant%20a%20security%20update|Issues that warrant a security update]]". * Attach your work * in the case of a patch (using the same upstream version), attach your suggested patch ([[PackagingGuide/Recipes/Debdiff|Howto Debdiff]]). For security updates, please see the [[SecurityTeam/UpdatePreparation#Packaging|security update packaging guidelines]]. * if the package uses a patch system (run `what-patch` in the source tree to find out), use `edit-patch` to comply with the choice of patch system, then make sure to follow the [[UbuntuDevelopment/PatchTaggingGuidelines|patch tagging guidelines]]. Package specific patch tags may be documented in `debian/README.source`. * review [[UbuntuDevelopment/Patches|our general patch guidelines]] that give tips how to get the patch included upstream as well. * in the case of a upstream version update ([[PackagingGuide/Recipes/PackageUpdate|Howto Package Update]]) attach the `.diff.gz` file (and link to the new upstream source if necessary) * Subscribe `ubuntu-sponsors` or `ubuntu-security-sponsors` as appropriate (details below) |
| Line 20: | Line 28: |
| * 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 |
=== Packages maintained on Launchpad 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. [...] $ |
| Line 30: | Line 43: |
| The script will ask you for your GPG passphrase to sign the bug report. It automatically uses gnome-gpg if it is installed. |
In these cases please consider registering a [[https://help.launchpad.net/BranchMergeProposals|Merge proposal]]. It will make the life of the maintainers a lot easier. |
| Line 33: | Line 45: |
| You can see the currently pending requests at: * https://launchpad.net/people/ubuntu-main-sponsors/+subscribedbugs * https://launchpad.net/people/ubuntu-universe-sponsors/+subscribedbugs Or combined at: * http://daniel.holba.ch/sponsoring/ |
=== Forwarding Patches Upstream === <<Include(PackagingGuide/Intro/PatchesForwarding, , from="StartEnglish", to="EndEnglish")>> |
| Line 39: | Line 48: |
| Do not assign a bug to anyone if it needs sponsorship. (See Workflow, below.) | === New Packages === |
| Line 41: | Line 50: |
| === Alternative approach using ppaput === | The process for getting NEW packages (packages which are not in Ubuntu at all yet) reviewed is explained at [[UbuntuDevelopment/NewPackages]]. |
| Line 43: | Line 52: |
| ==== Prerequisites ==== | == Consult the Release Schedule == <<Include(PackagingGuide/Howtos/ReleaseCycle, , from="StartEnglish", to="EndEnglish")>> |
| Line 45: | Line 55: |
| 1. Install `ubuntu-dev-tools` from Gutsy. 1. Set up your [https://help.launchpad.net/PPAQuickStart PPA]. 1. Also you need to copy your Launchpad cookie to `~/.lpcookie.` * Firefox uses `~/.mozilla/firefox/<random>cookies.txt`, * Epiphany uses `~/.gnome2/epiphany/mozilla/epiphany/cookies.txt`. |
== Getting Help == '''To be set up during Natty cycle.''' |
| Line 51: | Line 58: |
| Inspired by [[http://wiki.bazaar.canonical.com/PatchPilot|Bazaar's Patch Pilot programme]] there will be patch pilots in `#ubuntu-devel` who can help you get your patch accepted. Check the topic to see who's on duty. | |
| Line 52: | Line 60: |
| ==== Following up on an already filed bug ==== | Some notes: * Please respect that these people might have a few other patches in their queue already. * The package you have a question have about might not necessarily be part of the patch pilot's area of expertise. They will still try to help you get your fix in and probably get you in touch with the 'right' people. |
| Line 54: | Line 64: |
| 1. {{{cd sourcetree-1.2.3 }}} 1. add a changelog entry including `(LP: #123456)` (ClosingBugsFromChangelog) 1. {{{ppaput my-ppa -sa }}} will * build a source package * upload the whole source package (including tarball - `-sa` option) to the dput location called `my-ppa` * follow up on the bug report * subscribe the right people |
Generally asking for help in `#ubuntu-motu` or `#ubuntu-devel` is definitely on topic too. :-) |
| Line 64: | Line 66: |
| The general difference between sponsors and patch pilots is: * sponsors will pick items from the queue based on their preference (be it urgency or area of expertise, etc.) * patch pilots make themselves available on IRC (indicated in the topic in `#ubuntu-devel`) * patch pilots follow [[http://wiki.bazaar.canonical.com/PatchPilot|these instructions]] to get patches ready, not necessarily upload them, but do their best to get the item reviewed and it to a state where it can be included |
|
| Line 65: | Line 71: |
| ==== Filing a new bug ==== 1. {{{cd somenewpackage-1.0.0 }}} 1. {{{ppaput -n my-ppa -sa }}} will * file a new bug * add a changelog entry à la `(LP: #123456)` (ClosingBugsFromChangelog) * upload the whole source package (including tarball - `-sa` option) to the dput location called `my-ppa` * subscribe the right people to the bug ==== More information on ppaput ==== * File bugs at http://launchpad.net/ubuntu/+source/ubuntu-dev-tools * UbuntuDevTools * {{{man ppaput }}} |
|
| Line 86: | Line 74: |
| '''To review Ubuntu merge proposals, check out [[http://packaging.ubuntu.com/html/udd-uploading.html | these UDD instructions]]'''. | |
| Line 87: | Line 76: |
| Sponsorship is organized by two teams: | Sponsorship is organized into two teams: * https://launchpad.net/~ubuntu-sponsors * https://launchpad.net/~ubuntu-security-sponsors |
| Line 89: | Line 80: |
| * 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 94: | Line 84: |
| 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://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors * https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors&field.component=3&field.component=4 * https://bugs.launchpad.net/~ubuntu-security-sponsors/+subscribedbugs Or combined at: * '''http://reports.qa.ubuntu.com/reports/sponsoring/index.html''' |
| Line 99: | Line 91: |
| Save the email in raw text form, and do: {{{ apt-get source package cd package-* gpg -o - /path/to/saved/email | patch -Elp1 }}} |
~-(occasionally it may be useful to check if there are non-/ubuntu bugs that fail to be noticed: https://bugs.launchpad.net/bugs/+bugs?field.subscriber=ubuntu-sponsors) -~ |
| Line 105: | Line 93: |
| You should check the signature verification result. If you are processing the universe sponsorship queue, please review the Draft [: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`! === New Packages === The process for getting NEW packages (packages which are not in Ubuntu at all yet) reviewed is explained at ["MOTU/Packages/New"]. |
The `ubuntu-sponsors` team handles general sponsorship of packages in Ubuntu; the `ubuntu-security-sponsors` team handles sponsorship of packages in the `security` pocket for all components. |
| Line 120: | Line 96: |
| === Workflow === | == Workflow for Review and Sponsorship == |
| Line 122: | Line 98: |
| To find changes for main that need sponsoring, see the list of bugs: https://launchpad.net/people/ubuntu-main-sponsors/+subscribedbugs or http://daniel.holba.ch/sponsoring/ |
If you are processing the universe sponsorship queue, please review the [[UbuntuDevelopment/CodeReviews]], [[MOTU/Sponsorship/SponsorsQueue|MOTU Sponsorship Procedure Documentation]], or [[SecurityTeam/SponsorsQueue]]. |
| Line 127: | Line 100: |
| 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 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. |
|
| Line 136: | Line 102: |
| [:CategoryProcess] | [[CategoryProcess]] |
Sponsorship
The sponsorship process is designed to allow prospective developers to have packages reviewed and uploaded. 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 UbuntuDevelopment/NewPackages process.)
Requesting Sponsorship
To make use of Ubuntu merge proposals, follow these easy steps:
The traditional process involves:
File an Ubuntu bug in Launchpad or follow up on an existing one. If you think this might be a security update, please review the security team's "Issues that warrant a security update".
- Attach your work
in the case of a patch (using the same upstream version), attach your suggested patch (Howto Debdiff). For security updates, please see the security update packaging guidelines.
if the package uses a patch system (run what-patch in the source tree to find out), use edit-patch to comply with the choice of patch system, then make sure to follow the patch tagging guidelines. Package specific patch tags may be documented in debian/README.source.
review our general patch guidelines that give tips how to get the patch included upstream as well.
in the case of a upstream version update (Howto Package Update) attach the .diff.gz file (and link to the new upstream source if necessary)
Subscribe ubuntu-sponsors or ubuntu-security-sponsors as appropriate (details below)
Packages maintained on Launchpad 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. [...] $
In these cases please consider registering a Merge proposal. It will make the life of the maintainers a lot easier.
Forwarding Patches Upstream
New Packages
The process for getting NEW packages (packages which are not in Ubuntu at all yet) reviewed is explained at UbuntuDevelopment/NewPackages.
Consult the Release Schedule
Getting Help
To be set up during Natty cycle.
Inspired by Bazaar's Patch Pilot programme there will be patch pilots in #ubuntu-devel who can help you get your patch accepted. Check the topic to see who's on duty.
Some notes:
- Please respect that these people might have a few other patches in their queue already.
- The package you have a question have about might not necessarily be part of the patch pilot's area of expertise. They will still try to help you get your fix in and probably get you in touch with the 'right' people.
Generally asking for help in #ubuntu-motu or #ubuntu-devel is definitely on topic too. 
The general difference between sponsors and patch pilots is:
- sponsors will pick items from the queue based on their preference (be it urgency or area of expertise, etc.)
patch pilots make themselves available on IRC (indicated in the topic in #ubuntu-devel)
patch pilots follow these instructions to get patches ready, not necessarily upload them, but do their best to get the item reviewed and it to a state where it can be included
Sponsoring
To review Ubuntu merge proposals, check out these UDD instructions.
Sponsorship is organized into 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://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors
https://bugs.launchpad.net/~ubuntu-security-sponsors/+subscribedbugs
Or combined at:
(occasionally it may be useful to check if there are non-/ubuntu bugs that fail to be noticed: https://bugs.launchpad.net/bugs/+bugs?field.subscriber=ubuntu-sponsors)
The ubuntu-sponsors team handles general sponsorship of packages in Ubuntu; the ubuntu-security-sponsors team handles sponsorship of packages in the security pocket for all components.
Workflow for Review and Sponsorship
If you are processing the universe sponsorship queue, please review the UbuntuDevelopment/CodeReviews, MOTU Sponsorship Procedure Documentation, or SecurityTeam/SponsorsQueue.
SponsorshipProcess (last edited 2023-11-30 23:02:43 by bdrung)