CodeReviews
|
Size: 1000
Comment:
|
Size: 3101
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| '''¡¡¡ This is Work In Progress !!!''' | == Team Purpose == |
| Line 9: | Line 9: |
| If you are a member of the UbuntuDevelopers, it's highly appreciated if you join the team and help out: https://launchpad.net/~ubuntu-code-reviewers | If you are a member of the UbuntuDevelopers, it's highly appreciated if you join the team and help out: * https://launchpad.net/~ubuntu-main-sponsors * https://launchpad.net/~ubuntu-universe-sponsors == Workflow == Members of the team * have either to be in `~ubuntu-core-dev` (for `main`/`restricted`) or `~ubuntu-dev` (for `universe`/`multiverse`) to be able to upload reviewed patches. Still efforts of interested new contributors in reviewing patches are appreciated, * will triage bugs (in the bug lists mentioned above) weekly, * pick bugs they're interested (based on their area of expertise and preference), * assign bugs where a review might take longer to themselves to avoid duplication of work. If the patch was deemed not to be good enough yet, the bug will be re-assigned to the patch author and set to `In Progress`. The preferred way of closing bugs is ClosingBugsFromChangelog. The administrators of the team will * review the list of bugs weekly, * assign long standing bugs (>= 2 weeks) to team members who might be up to the job. Possible conflicts and problems will be discussed in the last minutes of the weekly Distro Team meeting. == Review == As a reviewer you should make sure the following rules are observed: * adhere to StableReleaseUpdates, FreezeExceptionProcess, SyncRequestProcess, Merge policy, * patches should apply, the resulting package should build and work correctly, built packages should install cleanly, * don't hesitate to let the patch go through several review iterations, if you're unsure or unhappy about it. * sync requests don't needs sponsoring or uploads; if you're sufficiently happy with the sync request of a non team member, simply * mark it as confirmed, * add your ''ACK'' in a comment, * unsubscribe the sponsors team, * subscribe `ubuntu-archive` to the bug. * keep the name of the patch author in `debian/changelog` and use `-k<keyid>` to sign the package with your key. * make sure to ask the patch author to submit the patch to Debian and/or Upstream. http://daniel.holba.ch/sponsoring/ has an overview of the bugs in those lists with assignees. |
| Line 14: | Line 48: |
| * https://help.launchpad.net/PPAQuickStart | |
| Line 17: | Line 52: |
| * SponsorshipProcess * SyncRequestProcess |
Team Purpose
A team of UbuntuDevelopers has agreed on doing periodical reviews of code. To accelerate SponsorshipProcess members of the team will check
the main/restricted sponsoring queue: http://bugs.launchpad.net/~ubuntu-main-sponsors
the universe/multiverse sponsoring queue: http://bugs.launchpad.net/~ubuntu-universe-sponsors
needs-packaging bugs that are marked as Fix Committed: https://bugs.launchpad.net/ubuntu/+bugs?field.status%3Alist=Fix+Committed&field.tag=needs-packaging
If you are a member of the UbuntuDevelopers, it's highly appreciated if you join the team and help out:
Workflow
Members of the team
have either to be in ~ubuntu-core-dev (for main/restricted) or ~ubuntu-dev (for universe/multiverse) to be able to upload reviewed patches. Still efforts of interested new contributors in reviewing patches are appreciated,
- will triage bugs (in the bug lists mentioned above) weekly,
- pick bugs they're interested (based on their area of expertise and preference),
- assign bugs where a review might take longer to themselves to avoid duplication of work.
If the patch was deemed not to be good enough yet, the bug will be re-assigned to the patch author and set to In Progress. The preferred way of closing bugs is ClosingBugsFromChangelog.
The administrators of the team will
- review the list of bugs weekly,
assign long standing bugs (>= 2 weeks) to team members who might be up to the job.
Possible conflicts and problems will be discussed in the last minutes of the weekly Distro Team meeting.
Review
As a reviewer you should make sure the following rules are observed:
adhere to StableReleaseUpdates, FreezeExceptionProcess, SyncRequestProcess, Merge policy,
- patches should apply, the resulting package should build and work correctly, built packages should install cleanly,
- don't hesitate to let the patch go through several review iterations, if you're unsure or unhappy about it.
- sync requests don't needs sponsoring or uploads; if you're sufficiently happy with the sync request of a non team member, simply
- mark it as confirmed,
add your ACK in a comment,
- unsubscribe the sponsors team,
subscribe ubuntu-archive to the bug.
keep the name of the patch author in debian/changelog and use -k<keyid> to sign the package with your key.
- make sure to ask the patch author to submit the patch to Debian and/or Upstream.
http://daniel.holba.ch/sponsoring/ has an overview of the bugs in those lists with assignees.
References
["MOTU/Sponsorship/SponsorsQueue"] - Emmet Hikory wrote up an excellent guide to getting the universe queue under control.
- Process documentation
Go back to [:UbuntuDevelopment].BR CategoryProcess
UbuntuDevelopment/CodeReviews (last edited 2023-08-21 12:01:15 by kewisch)