SponsorsQueue

Differences between revisions 1 and 28 (spanning 27 versions)
Revision 1 as of 2007-05-24 06:17:48
Size: 4287
Editor: p1033-ipbf37marunouchi
Comment: Initial Draft
Revision 28 as of 2011-12-10 01:26:53
Size: 5658
Editor: allison
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<Include(MOTU/Headers/WikiMergeUbuntuDev)>>

## page was renamed from MOTU/SandBox/UniverseSponsorsQueue
Line 5: Line 8:
 The [https://bugs.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs Universe Sponsors Queue] is used for [:MOTU/Contributors:Contributors] who have not yet been granted upload permission to the Ubuntu archives to submit changes to packages for review. It is intended to be used to solicit sponsorship of uploads for new package revisions and to request approval for SYNC requests. Example bugs that should belong to this queue include: SYNC Requests, MERGE Requests, and bugs for which a patch is available and has been packaged to represent a new revision for release. The [[http://reports.qa.ubuntu.com/reports/sponsoring/|Sponsors Queue]] is used by [[MOTU/Contributing|Contributors]] who have not yet been granted upload permission to the Ubuntu archives to submit changes to packages for review.
Please remember that:

 * Security fixes should follow the procedure outlined in the [[https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures|Security Update Procedure]].
 * Freeze exceptions should follow the procedure outlined in the [[https://wiki.ubuntu.com/FreezeExceptionProcess|Freeze Exception Process]].
 * Stable Release Updates (SRU) should follow the procedure outlined in the [[StableReleaseUpdates|SRU process]].
 * New packages should follow the [[UbuntuDevelopment/NewPackages]] procedure.
Line 9: Line 18:
 Before subscribing ubuntu-universe-sponsors to a bug, please check the following: Before '''subscribing''' ubuntu-sponsors to a bug, please check the following:
Line 11: Line 20:

 1 Your patch is in debdiff format.
 1 Your patch is in [[https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff|debdiff]] format (for merges and bug fixes) or a diff.gz file(for new upstream revisions).
Line 15: Line 23:
 2 The debdiff is targeted against the appropriate environment.
  * You can check the versions currently in each distribution from {{{https://launchpad.net/ubuntu/+source/packagename}}}. If your patch is not a [:MOTU/SRU:Stable Release Update], it should target the most recent revision. If it is a [:MOTU/SRU:Stable Release Update], it should target the Released revision for the stable release you are updating.
  * Check your .changes file to make sure that you have the right revision and distribution.
 2 The patch is targeted against the current development environment
  * Unless you are processing a [[StableReleaseUpdates|Stable Release Update]], the patch should be against the current development environment. Check {{{https://launchpad.net/ubuntu/+source/packagename}}} to make sure that you are working from the latest sources.
  * Check your {{{.changes}}} file to make sure that you have the right revision and distribution.
Line 20: Line 28:
  * Review the patch manually. If there are unexpected changes, consider removing them from the patch, either using filterdiff or manually. If you are uncertain, seek advice from #ubuntu-motu or your mentor.   * Review the patch manually. If there are unexpected changes, consider removing them from the patch, either using {{{filterdiff}}} or manually. If you are uncertain, seek advice from #ubuntu-motu or your [[MOTU/Mentoring|Mentor]]
Line 23: Line 31:
  * Test your patch by downloading and unpacking the target source, and running `patch -p0 patchname.debdiff` in the directory containing the .dsc file. There should be no errors.   * Test your patch by downloading and unpacking the target source, and running {{{patch -p1 < ../patchname.debdiff}}} in the package directory. There should be no errors.
Line 25: Line 33:
== Queue Processing Process ==  5 The Status and Assignment are correct
  * The Status should be "New" for sync requests
  * The Status should be "Incomplete" for freeze exceptions
  * The Status should be "Confirmed" for bugs that represent a new candidate revision (e.g. bugfix uploads, merges.) In other words, use Status "Confirmed" when you have uploaded a debdiff that requires attention from a sponsor.
  * The Assignment should be "Nobody"
Line 27: Line 39:
 Once you have selected a bug, pleae use the following guidelines for disposition. When selecting bugs, please limit yourself to "Unconfirmed" and "Confirmed" bugs.  6 The sponsors will use the status and assignment fields in their communications with you and other groups
  * Please check status and assignment before subscribing again a bug which required some actions (either from you or somebody else)
Line 29: Line 42:
== Note for Sponsors ==
Line 30: Line 44:
 * All bugs
  * Unsubscribe ubuntu-universe-sponsors
Once you have selected a bug, please use the following guidelines for disposition. When selecting bugs, please limit yourself to "New", "Incomplete" and "Confirmed" bugs.

=== All bugs ===

  * Unsubscribe ubuntu-sponsors
Line 33: Line 50:
  * Set the Status to "In-Process"   * Set the Status to "In Progress"
Line 35: Line 52:
 * Bugs against packages in main
  * If unset, set the importance. (Default: "Wishlist")
  * If not present, add the "patch" tag
  * Assign "Nobody" and set Status to "Confirmed"
  * Add a comment including the following:
   * That ubuntu-universe-sponsors has been unsubscribed.
   * That the package is in main
   * That ubuntu-main-sponsors has been subscribed to process the request
   * Subscribe ubuntu-main-sponsors
=== Sync request bugs ===
Line 45: Line 54:
 * SYNC Request bugs
* If unset, set the importance. (Default: "Wishlist")
  * If unset, set the importance. (default: "Wishlist")
Line 49: Line 57:
  * If the SYNC is acceptable   * If the sync is acceptable
Line 52: Line 60:
   * Add a comment "SYNC Request ACK'd"    * Add a comment "sync request ACK'd"
Line 54: Line 62:
   * Unsubscribe ubuntu-sponsors
Line 55: Line 64:
  * If the SYNC is not acceptable
   * Assign the submitter and set the Status to "Rejected"
   * Add a comment explaining why the SYNC is not acceptable
  * If the sync is not acceptable
   * Assign the submitter and set the Status to "Invalid"
   * Add a comment explaining why the sync is not acceptable
Line 59: Line 68:
 * Bugs with Debdiffs
  * If unset, set the importance. (Default: "Wishlist")
=== Bugs with debdiffs ===

  * If unset, set the importance. (default: "Wishlist")
Line 63: Line 73:
   * Upload the resulting package
   * Set the Status to Fix Committed
   * Add the source.changes file as a comment
   * Upload the resulting package. Since you're not the top person listed in the changelog, you will need to use the -k switch when running dpkg-buildpackage.
   * Update the status to "Fix Committed"
   * Add comment that the fix has been uploaded.

  * If the debdiff is for an SRU, and looks sane, but you are unsure about uploading
   * If the bug is already tagged motu-sru-verification, upload it.
   * Otherwise:
    * Ask in #ubuntu-motu for a second opinion
    * In the absence of a second opinion:
     * Add the motu-sru-verification tag
     * unassign yourself, and set status to "Confirmed"
Line 69: Line 87:
   * When complete, Set status to Fix Committed & add source.changes as a comment    * When complete, upload as usual
Line 72: Line 90:
   * Set the Status to "Needs Info"    * Set the Status to "Incomplete"
Line 75: Line 93:
    * That ubuntu-universe-sponsors has been unsubscribed     * That ubuntu-sponsors has been unsubscribed
Line 77: Line 95:
    * That the contributor should resubscribe U-U-S when the changes are complete     * That the contributor should resubscribe ubuntu-sponsors when the changes are complete
Line 79: Line 97:
 * Bugs Without debdiff === Bugs without debdiffs ===
Line 82: Line 101:
  * (optional) Set the Importance
Line 83: Line 103:
   * That U-U-S has been unsubscribed    * That ubuntu-sponsors has been unsubscribed
Line 85: Line 105:
   * That a debdiff patch should be created prior to resubscribing U-U-S    * That a debdiff patch should be created prior to resubscribing ubuntu-sponsors

N.B.: normal bug triage rules still apply. Inappropriate bugs should be invalidated. Already fixed bugs should be updated as Released with the release version, etc.


----
[[CategoryProcess]]<<BR>>
[[CategoryMOTUUbuntuDevMerge]]

Warning /!\

The MOTU team is pondering merging this page with UbuntuDevelopment, expect an announcement on ubuntu-motu@lists.ubuntu.com soon.
If you want to make changes to this page, ask in #ubuntu-motu or on the MOTU mailing list for a better place for those changes.

Universe Sponsors Queue

Purpose

The Sponsors Queue is used by Contributors who have not yet been granted upload permission to the Ubuntu archives to submit changes to packages for review. Please remember that:

Notes for Contributors

Before subscribing ubuntu-sponsors to a bug, please check the following:

  • 1 Your patch is in debdiff format (for merges and bug fixes) or a diff.gz file(for new upstream revisions).

    • If it is just a patch against the source, please consider adding the "patch" tag, so that other contributors can easily find the patch and create a debdiff.
    2 The patch is targeted against the current development environment
    • Unless you are processing a Stable Release Update, the patch should be against the current development environment. Check https://launchpad.net/ubuntu/+source/packagename to make sure that you are working from the latest sources.

    • Check your .changes file to make sure that you have the right revision and distribution.

    3 All changes in the patch are intentional
    • Review the patch manually. If there are unexpected changes, consider removing them from the patch, either using filterdiff or manually. If you are uncertain, seek advice from #ubuntu-motu or your Mentor

    4 Your patch applies cleanly
    • Test your patch by downloading and unpacking the target source, and running patch -p1 < ../patchname.debdiff in the package directory. There should be no errors.

    5 The Status and Assignment are correct
    • The Status should be "New" for sync requests
    • The Status should be "Incomplete" for freeze exceptions
    • The Status should be "Confirmed" for bugs that represent a new candidate revision (e.g. bugfix uploads, merges.) In other words, use Status "Confirmed" when you have uploaded a debdiff that requires attention from a sponsor.
    • The Assignment should be "Nobody"
    6 The sponsors will use the status and assignment fields in their communications with you and other groups
    • Please check status and assignment before subscribing again a bug which required some actions (either from you or somebody else)

Note for Sponsors

Once you have selected a bug, please use the following guidelines for disposition. When selecting bugs, please limit yourself to "New", "Incomplete" and "Confirmed" bugs.

All bugs

  • Unsubscribe ubuntu-sponsors
  • Assign yourself
  • Set the Status to "In Progress"

Sync request bugs

  • If unset, set the importance. (default: "Wishlist")
  • If not present, add the "sync" tag.
  • If the sync is acceptable
    • Set the Status to "Confirmed"
    • Assign to "Nobody"
    • Add a comment "sync request ACK'd"
    • Subscribe ubuntu-archive
    • Unsubscribe ubuntu-sponsors
  • If the sync is not acceptable
    • Assign the submitter and set the Status to "Invalid"
    • Add a comment explaining why the sync is not acceptable

Bugs with debdiffs

  • If unset, set the importance. (default: "Wishlist")
  • If the debdiff is good
    • Upload the resulting package. Since you're not the top person listed in the changelog, you will need to use the -k switch when running dpkg-buildpackage.
    • Update the status to "Fix Committed"
    • Add comment that the fix has been uploaded.
  • If the debdiff is for an SRU, and looks sane, but you are unsure about uploading
    • If the bug is already tagged motu-sru-verification, upload it.
    • Otherwise:
      • Ask in #ubuntu-motu for a second opinion
      • In the absence of a second opinion:
        • Add the motu-sru-verification tag
        • unassign yourself, and set status to "Confirmed"
  • If additional changes to the source are planned (soon)
    • Add comment that you are working on additional changes
    • When complete, upload as usual
  • If the patch needs work
    • Set the Status to "Incomplete"
    • Assign the patch submitter
    • Add a comment including the following:
      • That ubuntu-sponsors has been unsubscribed
      • The specific work that must be done for the patch to be acceptable
      • That the contributor should resubscribe ubuntu-sponsors when the changes are complete

Bugs without debdiffs

  • If there is a patch, and no patch tag, add the patch tag
  • Assign "Nobody" and Set status "Confirmed"
  • (optional) Set the Importance
  • Add a comment including the following:
    • That ubuntu-sponsors has been unsubscribed
    • (optional) any notes from reviewing the patch
    • That a debdiff patch should be created prior to resubscribing ubuntu-sponsors

N.B.: normal bug triage rules still apply. Inappropriate bugs should be invalidated. Already fixed bugs should be updated as Released with the release version, etc.


CategoryProcess
CategoryMOTUUbuntuDevMerge

MOTU/Sponsorship/SponsorsQueue (last edited 2011-12-10 01:26:53 by allison)