| 1 |
On Mon, Jul 6, 2015 at 9:42 AM, Peter Stuge <peter@×××××.se> wrote: |
| 2 |
|
| 3 |
> Alec Warner wrote: |
| 4 |
> > Its difficult to make a large change like "all commits require review", |
| 5 |
> > particularly for long-time contributors who are expecting to move |
| 6 |
> quickly. |
| 7 |
> |
| 8 |
> I think it's a character flaw (maybe hubris due to lack of experience |
| 9 |
> and/or ignorance?) to lack the humility to say that I would prefer my |
| 10 |
> commits to be reviewed by peers. |
| 11 |
> |
| 12 |
|
| 13 |
Oh I'm not making that argument (its a tough one anyway.) |
| 14 |
|
| 15 |
I haven't done any research in Gentoo in terms of error rates (how many), |
| 16 |
who makes errors (newbies? oldbies? everyone?), what the error impact is |
| 17 |
(minor, major, data loss?), and so on. |
| 18 |
|
| 19 |
On my old team at work we had code review, but it did not impact quality |
| 20 |
very much because (manual) review catches a pretty specific set of |
| 21 |
conditions some of the time. We had vastly superior quality by adopting |
| 22 |
linters (to prevent really dumb mistakes that code review also didn't catch |
| 23 |
consistently) and fast[1] enough automated testing that caught large |
| 24 |
subsets of other really common errors. Of course, these are all quite low |
| 25 |
hanging fruit. |
| 26 |
|
| 27 |
[1] for some subset of fast; I think tests still took 5 minutes or so. |
| 28 |
|
| 29 |
> |
| 30 |
> It is obviously easier to stick my head in the sand, but then I |
| 31 |
> should probably keep my crap in an overlay. (I do, and am happy!) |
| 32 |
> |
| 33 |
> If I were committing to gentoo I would want help from my peers to |
| 34 |
> ensure that what I commit is not just done well but also done right. |
| 35 |
> |
| 36 |
|
| 37 |
I think the past has proven that not all Gentoo developers feel this way (I |
| 38 |
never did; although I have not committed to the tree in some time.) |
| 39 |
|
| 40 |
|
| 41 |
> |
| 42 |
> |
| 43 |
> > I'd be curious how many subprojects use review |
| 44 |
> |
| 45 |
> I suspect that it's rare. Most developers are in my experience unable |
| 46 |
> to work with review. |
| 47 |
> |
| 48 |
> |
| 49 |
> > learning purposes. |
| 50 |
> |
| 51 |
> Another significant benefit of review, besides the obvious quality benefit. |
| 52 |
> |
| 53 |
> |
| 54 |
> > I'd also be curious what adoption of a code review system would be |
| 55 |
> > like if it was not required (but was available, and perhaps |
| 56 |
> > required for specific subprojects that adopt it.) |
| 57 |
> |
| 58 |
> I think this is a lovely idea! I'd really like that setup! |
| 59 |
> |
| 60 |
|
| 61 |
> |
| 62 |
> //Peter |
| 63 |
> |
| 64 |
> |
Archives