commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Who Commits to What
Date Fri, 01 Feb 2002 23:04:27 GMT
On Thu, 31 Jan 2002 23:37, Ted Husted wrote:
> Peter Donald wrote:
> > If you want for Avalon to move all its components across then there is
> > one thing that needs to be changed. Same thing as it was when Commons was
> > incepted, same thing I have been saying for ages. If working with Avalon
> > is not desired then nothing needs to be changed.
> Perhaps you've answered this before, and I've missed it, but how is
> commit and voting rights different in the Commons than on any large
> Jakarta subproject?

The number of committers, the level of interaction between committers and the 
ease of becoming a committer. 

Commons has a larger number of committers - the rate at which new committers 
are added is only going to increase as it grows. Lets assume theres 25 
committers now - I would not be surprised to see that this increased to 50 
within a year. So commons promotes quantity of committers.

Committers don't have the requirement to interact with other commons 
committers. It is a simple manner to get voted in when 90% of the commons 
group does not know the committer it doesn't matter. So interaction is not an 
important aspect of being a commons committer.

Committers also have a very easy way to get in - all they need to do is 
submit a componet and voila! They are in.

Compare this to any other project - large or not. I have no idea on the 
largest project (maybe TC?) so lets imagine it is TC. Even including all the 
current active committers in TC I suspect it would be far less than Commons? 
I suspect they all at least are aware of each other - even if they are 
segmented into TC3 vs TC4 (is that still true?). And I suspect TC also 
demands that the developers show a higher level of commitment before being 
nominated as committers.

> When the code is donated to a subproject, all Committers to
> the subproject have equal responsiblity for its maintenance and
> continued deveopment.

Now thats an interesting perspective. The ecletic mix of components and dev 
styles is unlikely to engender central control

> If it might fall to me to support something, then I should have a say
> over what I may need to support. Unilateral vetos only apply to product
> changes, and must be justifiable. You can't veto a release, or a plan,
> only real code or real documentation. A real veto must provide real
> alternatives or present real technical problems, or it is not
> justifiable. If you don't believe me, ask Brian or Roy.

It is easy enough to jig the system and come up with a "real" reason to veto 

> AFAIK, there is no precedent for saying a Committer to subproject can
> vote on this or that, but not on something else. Either the Commons is a
> subproject or it isn't.

Go read the jakarta docs again ;) It basically saids it is decision to be 
made by the subproject.

> If we are going to change the voting rights in the Commons, then we
> should bite the bullet and propose it as a top-level ASF Project, 


> and
> perhaps ask the XML Commons to join us. The Commons could then have its
> own PMC, and parcel out the commit and voting rights any way it saw fit.

Why not just sourceforge management scripts because that would mean even less 
work for this new PMC.



"Marriage, Friends, Religon -- these are the demons 
you must slay in order to suceed in business.." 
                 -- Mr. Burns, The Simpsons 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message