launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On October 19, 2010, Jeroen Vermeulen wrote:
> On 2010-10-19 17:28, Julian Edwards wrote:
> > On Tuesday 19 October 2010 02:53:10 Robert Collins wrote:
> >> What do you think?
> > 
> > So basically, you want to bring back [r=trivial] ?
> 
> To those who missed preceding episodes: Julian is referring to the old 
> days when we did allow unreviewed landings.
> 
> It was decided that the practice did more harm than good, and a choice 
> was made: try to get faster reviews, not fewer.  We probably sputtered a 
> bit, but once we made the change we never looked back.

There is only a superficial resemblance with the trivial tag. It looks like a 
cycle, but it's actually a spiral.

Back when we had trivial, the set of reviewers was much restricted. The whole 
team has now a lot more experience, both as coders and reviewers. 

Also, we never really reviewed how trivial made things better. It was deemed 
necessary that all changes be reviewed, but there was never an empirical 
retrospective of that decision since then.

Here Robert is actually proposing an experimental framework to assess our 
beliefs that allowing landing unreviewed changes is actually a bad idea.

Also by calling it unreviewed, the claim isn't that the changes are trivial, 
just that the cost of reviewing the changes outweights any benefit.

Also, this policy takes a 'we are responsible adults stance'. It trusts that:

- Launchapd engineers know the coding convention, value them and honors them 
(they may make mistake in them sometime, we don't care enough to enfore them 
before landing, let's clean up anything missed post-hoc.)

- We are a mature team that knows the value of peer-feedback, and engineers 
will seek out that feedback when necessary

- We are a mature team that instead of cramming to meet deadline with low 
quality, values flow and fast cadence without compromising code quality. In 
that regards, we remove the most friction in getting changes in and trust that 
engineers will seek out reviews appropriately.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.