On Wed, Oct 23, 2002 at 04:50:10PM -0700, Greg Stein wrote: > On Tue, Oct 22, 2002 at 12:34:27AM -0700, Aaron Bannert wrote: > >... > > When a veto is cast, it must be accompanied by technical justification > > and should also include an alternative proposal. I just don't think > > that people who aren't involved in a project at a code level can > > make valid technical justifications. Maybe that is the beauty of > > the system, since if non-contributors can't make valid technical > > justifications, then we don't have to worry about spurrious vetos. :) > > This is a *very* important point. There has been significant talk about > improper veto usage in some projects. To prevent that kind of misuse, a veto > *must* have technical justification. >
Excellent. Thank you, I will reference this email many, many times ;) > Note the contrast with the "all j-c committers have voting rights on all j-c > components." I do not believe that works, and will not vote-for/support such > a model for the Apache Commons. I think the model will be multiple > components within the Commons, with associated groups of committers and > voters. The 'intent' (IMHO, of course) of the j-c commit model, was that everyone had avail access to all code, but you had to add yourself as a member of the project before you committed to it. This was ultimately end run where people would just add themselves and then veto, but I think the general idea of gaining access to a project is a good idea. The most useful thing here is that since j-c has so many smaller projects (in terms of code size), that anyone willing to review and commit a patch is a good thing. If you don't know much about the component, you don't commit the patch, but if you have a good idea about, but just not the bandwidth to completly participate, commit the patch. Some may disagree with this, but I am a firm beleiver, as the codebase size approaches zero. -- Scott Sanders - [EMAIL PROTECTED]
