You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ted Husted <hu...@apache.org> on 2002/01/31 13:37:48 UTC

Re: Who Commits to What

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?

I assume that an Avalon committer that has worked exclusively on
Excalibur would have voting rights on the Framework too. Avalon is
Avalon, a committer is a committer. 

We don't require the same degree of community behind every packgae in
the Commons, because Committers to other Commons package can step up to
bat if the usual developer is distracted. That's the way Meritocracy
works. We watch each other's back. It's not your code, or my code, it's
our code. When the code is donated to a subproject, all Committers to
the subproject have equal responsiblity for its maintenance and
continued deveopment. 

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.

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. 

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.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Who Commits to What

Posted by Peter Donald <pe...@apache.org>.
On Sat, 2 Feb 2002 11:02, costinm@covalent.net wrote:
> I would have no problem if all jakarta commiters would have the right
> to vote on tomcat. 

eek! Thank god that would never get through the other developers or there 
would be flame wars bonanza ;)

> I would be happy to propose any jakarta commiter who
> is interested in contribution or voting on tomcat as a tomcat commiter.
> And I will +1 any other jakarta commiter that is proposed as a tomcat
> commiter. 

Do these people have to be jakarta commiters? Could they be part of 
xml.apache.org? How about part of GNU Classpath? What about someone who is 
part of Suns marketing department?

-- 
Cheers,

Pete

"abandon all hope , ye who enter here" - dante, inferno

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Who Commits to What

Posted by co...@covalent.net.
On Sat, 2 Feb 2002, Peter Donald wrote:

> 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.

I would have no problem if all jakarta commiters would have the right
to vote on tomcat. I would be happy to propose any jakarta commiter who
is interested in contribution or voting on tomcat as a tomcat commiter.
And I will +1 any other jakarta commiter that is proposed as a tomcat
commiter. Including Peter :-)

BTW, using code from another jakarta project is the same as
trusting the commiters of that project.

Tomcat is using commons code, so we do seem to trust the commons
community. The fact that a lot of tomcat commiters can vote
on all commons component that they use seems to make us very
comfortable with using commons and  migrating code from
tomcat that is of common interest into commons.

The same doesn't seem to happen with Avalon - and I don't know
why, but that's not our problem but Avalon's problem. It may
have the goal to create 'server side components', but tomcat
as a server doesn't seem to use any. And it may have the goal
of creating 'components', but so far it seems many people
prefer commons for that.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Who Commits to What

Posted by Peter Donald <pe...@apache.org>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>