CodeReviews

Differences between revisions 2 and 4 (spanning 2 versions)
⇤ ← Revision 2 as of 2007-07-03 11:19:36 →
Size: 1024
Editor: i59F76E35
Comment:
← Revision 4 as of 2007-07-05 11:10:25 → ⇥
Size: 2371
Editor: i59F7228F
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

== Team Purpose ==
Line 10: Line 12:

== 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, 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.

¡¡¡ 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, 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.

References

Go back to [:UbuntuDevelopment].BR CategoryProcess

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