Diff for "PolicyAndProcess/OptionalReviews"

Not logged in - Log In / Register

Differences between revisions 6 and 7
Revision 6 as of 2010-11-07 19:18:25
Size: 2204
Editor: lifeless
Comment: process tweaks
Revision 7 as of 2010-11-07 20:07:03
Size: 3092
Editor: lifeless
Comment: first week of cross-check audit
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:


=== Unreviewed landings ===

|| '''revno''' || '''branch''' || '''reviewer''' || '''would-review-be-worth-it''' || '''comments''' ||
|| 11874 || devel || lifeless || No || Updates a dependency. ||
|| 11855 || devel || lifeless || No || Clear fix with no alternative implementations. ||
|| 11851 || devel || lifeless || Yes || Added a edit-subscription facility for existing subscriptions - review caught a mismatch between subscribe and edit-subscription models. ||
|| 11842 || devel || lifeless || No || Fixed up a XXX landed while a dependent layer was fixed. ||
|| 11836 || devel || lifeless || No || Simple drop of unneeded dep combined with a testfix to trigger buildbot ||
|| 11827 || devel || lifeless || No || Totally mechanical, restructure along already agreed lines ||
|| 11823 || devel || lifeless || No || A testfix - fixing something landed without ec2land ||

  • Name: Optional Reviews

  • Owner: Technical Architect

  • Effective: Not yet

  • Review: Epic Jan 2011

  • Experiment Underway:

Process Overview

Some reviews are not needed and eligible developers can choose to have branches land without formal review.

Process Description

Launchpad reviewers can choose to land branches without review. Only 'code' reviews can be made optional. Javascript UI and Database patches are out of scope of the experiment.

For the first two weeks (until 12 Nov 2010) all unreviewed landings will be reviewed post landing by Robert.

Each month, all code reviewers will be assigned one unreviewed landed to do a post hoc review as part of assessing the experiment.

Production problems which are tracked to unreviewed landings will also be input into assessing the experiment.

Rationale

Not all changes benefit from code review / are high enough risk to need formal review. For instance (not exhaustive):

  • mechanical things (like moving code)
  • updating source deps
  • rollbacks
  • typo fixes
  • improvements to documentation

For many of these things a review may add value - but less value than doing the review uses up. We want reviews to be a net win for the effort being put into developing Launchpad, and so we should, once we're comfortable people know how things should be, allow them to decide if a particular change is an improvement on its own, or an improvement that also /needs/ other input before landing.

Triggers

Experienced developer (someone currently working on LP who has been doing so for the last 3 months) landing a code change (not UI or Database, for now : evaluate after assessing the success of optional code reviews).

Activities

  1. Submit the branch to create an MP (our toolchains can look at this and it provides a location for a post landing review if the branch has that done to it.)

  2. Self review without a review type.

  3. Land via the normal landing process.

Unreviewed landings

revno

branch

reviewer

would-review-be-worth-it

comments

11874

devel

lifeless

No

Updates a dependency.

11855

devel

lifeless

No

Clear fix with no alternative implementations.

11851

devel

lifeless

Yes

Added a edit-subscription facility for existing subscriptions - review caught a mismatch between subscribe and edit-subscription models.

11842

devel

lifeless

No

Fixed up a XXX landed while a dependent layer was fixed.

11836

devel

lifeless

No

Simple drop of unneeded dep combined with a testfix to trigger buildbot

11827

devel

lifeless

No

Totally mechanical, restructure along already agreed lines

11823

devel

lifeless

No

A testfix - fixing something landed without ec2land

PolicyAndProcess/OptionalReviews (last edited 2012-10-10 03:52:36 by lifeless)