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