CodeReviews

Differences between revisions 1 and 7 (spanning 6 versions)
⇤ ← Revision 1 as of 2007-07-03 11:11:01 →
Size: 1000
Editor: i59F76E35
Comment:
← Revision 7 as of 2007-07-05 11:24:42 → ⇥
Size: 2692
Editor: i59F7228F
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

== Team Purpose ==
Line 11: Line 13:
== Workflow ==

Members of the team
 * have either to be in `~ubuntu-core-dev` or `~ubuntu-dev` 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.
Line 17: Line 47:
  * SponsorshipProcess
  * SyncRequestProcess

¡¡¡ This is Work In Progress !!!

Team Purpose

A team of UbuntuDevelopers has agreed on doing periodical reviews of code. To accelerate SponsorshipProcess members of the team will check

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

Workflow

Members of the team

  • have either to be in ~ubuntu-core-dev or ~ubuntu-dev 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.

References

Go back to [:UbuntuDevelopment].BR CategoryProcess

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