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
something
> 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,
why?
> 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.
--
Cheers,
Pete
---------------------------------------------------
"Marriage, Friends, Religon -- these are the demons
you must slay in order to suceed in business.."
-- Mr. Burns, The Simpsons
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
