On Sun, 25 Apr 2010 05:01:17 -0700 Alec Warner <anta...@gentoo.org> wrote:
> On Sun, Apr 25, 2010 at 4:36 AM, Ryan Hill <dirtye...@gentoo.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 see fit. 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
signature.asc
Description: PGP signature
