2204
Comment: process tweaks
|
3092
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
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.)
Self review without a review type.
- 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 |