1 |
On Sun, 25 Apr 2010 05:01:17 -0700 |
2 |
Alec Warner <antarus@g.o> wrote: |
3 |
|
4 |
> On Sun, Apr 25, 2010 at 4:36 AM, Ryan Hill <dirtyepic@g.o> wrote: |
5 |
> > said eclasses need to be reviewed before committing. But enforcing it through |
6 |
> > cvs is never going to fly. Just use common sense. |
7 |
> |
8 |
> Sure it will; you just need to create the tools with flexibility in |
9 |
> mind. For instance: |
10 |
> |
11 |
> 1) Require peer review on all eclasses |
12 |
> 2) Do not require peer review for changes less than N lines |
13 |
> 3) enable a commiter to over-ride the review with some kind of option |
14 |
> (--force or similar) |
15 |
> 4) enable an eclass-owner to opt-out of the review process entirely |
16 |
> with some kind of flag. |
17 |
> |
18 |
> I am not aware of how robust the pre-commit hooks in cvs are so I |
19 |
> cannot comment on how easy these things are to implement. |
20 |
|
21 |
Well, I didn't mean technically. ;) But we could achieve the same general |
22 |
effect of the above without installing padlocks on cvs. Just let projects or |
23 |
teams establish their own review policies like they already do. For example, |
24 |
if you commit changes to toolchain.eclass without consulting Mike, you'll |
25 |
soon find an email in your inbox. If you mess with wxwidgets.eclass without |
26 |
running it by me you'll find your commit reverted. On the other hand, |
27 |
anyone in the font, X, or tex herds can modify font.eclass. Let people |
28 |
establish rules suited to their project's workflow and enforce them as they |
29 |
see fit. |
30 |
|
31 |
Again, if there were some evidence this isn't working then it should be |
32 |
presented. Otherwise I don't see any reason to change the status quo. |
33 |
|
34 |
|
35 |
-- |
36 |
fonts, by design, by neglect |
37 |
gcc-porting, for a fact or just for effect |
38 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |