Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
Date: Sun, 25 Apr 2010 12:01:38
Message-Id: z2mb41005391004250501of6467a7fh2428293bdc17f0de@mail.gmail.com
In Reply to: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits by Ryan Hill
1 On Sun, Apr 25, 2010 at 4:36 AM, Ryan Hill <dirtyepic@g.o> wrote:
2 > On Sun, 25 Apr 2010 13:11:11 +0300
3 > Petteri Räty <betelgeuse@g.o> wrote:
4 >
5 >> On 04/25/2010 01:06 PM, Ryan Hill wrote:
6 >
7 >> > I think it's a good idea to strongly encourage it, but actually forcing it
8 >> > through cvs?  No thanks.  I'm not tracking down another dev just to fix a
9 >> > spelling mistake. :P
10 >>
11 >> How did the spelling mistake get there in the first place? A review
12 >> system should reduce having them in the first place.
13 >
14 > People make mistakes.  Anyways my point is that requiring a peer review for
15 > trivial changes is just unneeded bureaucracy.  Even for non-trivial changes,
16 > it doesn't make sense to force someone who knows their eclass inside out and
17 > knows what they're doing to get a review from someone else who may not have a
18 > clue.  I'm not saying that peer-review shouldn't be done; it's a very good
19 > idea, especially if you're new, or unsure of your changes, or you have a team
20 > consisting of more than one person.  In fact I would support a policy that
21 > said eclasses need to be reviewed before committing.  But enforcing it through
22 > cvs is never going to fly.  Just use common sense.
23
24 Sure it will; you just need to create the tools with flexibility in
25 mind. For instance:
26
27 1) Require peer review on all eclasses
28 2) Do not require peer review for changes less than N lines
29 3) enable a commiter to over-ride the review with some kind of option
30 (--force or similar)
31 4) enable an eclass-owner to opt-out of the review process entirely
32 with some kind of flag.
33
34 I am not aware of how robust the pre-commit hooks in cvs are so I
35 cannot comment on how easy these things are to implement.
36
37 -A
38
39 >
40 > If we were having ongoing issues with people breaking eclasses then I could
41 > see where you're coming from.  But as it is, it's a non-problem.
42 >
43 >
44 > --
45 > fonts,                                            by design, by neglect
46 > gcc-porting,                              for a fact or just for effect
47 > wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
48 >

Replies