You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2002/05/25 01:06:58 UTC

[PROPOSAL] Committer access and responsibilities...

Chatted with a lot of people, seen many, different development models, went
around, asked, talked, and I believe I have a pretty decent picture, and
maybe even a solution...

So the major topic of discussion is that I perceive a substantial difference
between being able to commit code to a CVS repository, and being a
"committer" committer, with all dues and responsibilities that this role
concerns...

For example sometimes someone might want to have commit access just because
he is working for a company that deals with a particular project in Apache
(we've seen this happening several times with some projects such as Xerces
and Tomcat), but he really doesn't care about the whole fuzz of Apache and
stuff, and once the employment contract ends, the relationship with Apache
terminates as well (I don't need to enumerate all those examples along those
lines).

One other example, if we didn't have Henri building RPMs for basically all
Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
don't you think that he would deserve committer status even if he's not tied
to any particular codebase? We had this "problem" in the current election of
the members, Sally Khudairi: Sally doesn't code, but she was involved with
the ASF since before it was even created as a press organizer. Does she
deserve to be a member of the foundation? Even if she doesn't code? Yes she
does, IMO (and she was elected and nominated a member today)...

So, IMO, there's a great difference between being a coder, and being a
member of the Jakarta community, at least in my opinion. There might be
coders who are not involved with the community, and there might be
non-coders who are much involved with it, want to participate, are active
and deserve to be committers...

Our current structure doesn't "allow" that to happen, both things. If you
need to write code in a particular source-base, and you need CVS access, you
are automagically made a committer, even if you don't care about much else,
and if you're very much involved with the overall project, but not tied to
ANY whatsoever codebase, and really, don't want / can't do it.

So, given this little background, I would like to ask to the PMC, and all
other committers, if others agree that we should "splitting" the "committer"
figure in two parts:

- contributor: a contributor is someone who has access to a particular CVS
tree, but for any reason doesn't want/need to be involved with the whole
Jakarta community. He just wants to code his little bit and live a long
life.

- member: is someone who is involved with the Jakarta community, somehow,
somewhere (might be just giving a great deal in supporting users of our
projects, or providing extra value to projects, like guidance in respect to
overall specifications, binary builds). He is effectively a member of the
community and has all the rights and dues of every member, such as
participate in the election of the PMC.

And redefining the figure of the "committer" as follows:

- committer: is a contributor, but also a member, therefore he has all the
privileges and dues of a contributor (having CVS access, and overlooking the
code he's contributing to) and of a member (can vote for PMCs, should
participate and contribute to discussions on the overall structure of
Jakarta).

I believe this makes sense, more sense than what we have now, also because
we've seen that happening in the ASF for the very first time with a
non-coding member. Comments please?

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Ted Husted <hu...@apache.org>.
I changed "Developer" to "Contributer" throughout the guidelines, if 
for no other reason than to match the terminology of the "Contributor 
License" distributed by the ASF.

Personally, I feel that the current guidelines do express the concept
that committing is voting by lazy consensus. That's why there is a 
lazy consensus: so we can propose, vote, and make-it-so in one fell 
swoop. Volunteer time is a precious resource and we need to make 
the most of it. 

A substantial patch to the guidelines was proposed some time ago that
might help clarify this and other fine points. 

http://jakarta.apache.org/site/proposal.html


-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Leo Simons wrote:
> this is not quite reflective of our current situation. The term
> "developer" can sometimes be misleading ("contributor" would be better,
> perhaps), while "committer" perhaps should include some added guidelines
> wrt responsibilities.
> 
> You might call the fact that these definitions are somewhat out of whack
> a "systemic bottleneck".
> 
> > Since committing is voting, what I think what some people want is a
> > non-vetoing Committer.
> 
> I think 'some people' don't see/don't agree to the "committing is
> voting", and then what they want is a Developer-with-CVS-access, which
> is more or less what they said.
> 
> "Committing is voting" is not reflected in our guidelines (at least I
> couldn't find such a notion).
> 
> > Someone to do the work without sharing in the
> > responsibility.
> 
> sounds like what we call "developer" in our guidelines ;)
> 
> > Which is to say, we can reject what they do, but they
> > can't reject what we do. Personally, I would find that type of
> > master/slave relationship difficult to maintain in a volunteer
> > organization like this. If you are working hard enough to need commit
> > rights, you are working hard enough to have veto rights.
> 
> What if someone wants/needs commit rights but doesn't want the veto
> rights (and responsibilities)? The right to vote also means an
> obligation to vote/abstain. The implication of your statement is "if you
> are given cvs access, you should also take on the responsibility of
> voting".
> 
> cheers,
> 
> - Leo
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

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


RE: [PROPOSAL] Committer access and responsibilities...

Posted by Danny Angus <da...@apache.org>.
I agree with andy to an extent here:


> I do NOT think developers should be granted CVS access without voting
> rights.


But do still believe that there ought to be a more restrictive set of
permissions, and responsibilities, for "entry level"  sub-project
membership, if entry level members buy-in to the project community they will
learn where to ask to be proposed for full membership.

I think its important, getting back to the cause of this discussion to
reconcile the two ideals of firstly letting sub-projects manage their own
entry criteria, and secondly still maintaining a real community amongst
those with a wider horizon.

The problem Pier raised can be summarised as the entrance criteria of Tomcat
being percieved as too low w.r.t. the benefits and responsibilities a
commiter has within the wider Jakarta community, while acknowleding that
raising the bar would be Jakarta unfairly restricting the freedom Tomcat
mambers have in running their own community.

d.


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
Jon Scott Stevens wrote:

>on 5/29/02 1:47 PM, "Andrew C. Oliver" <ac...@apache.org> wrote:
>
>  
>
>>I got shot down by the POI community.
>>    
>>
>
>Sounds like a common thread, eh?
>  
>
Not sure what you mean.  How's the bar doing?

-Andy

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




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
On Thu, 2002-05-30 at 01:49, Ted Husted wrote:
> 
> If you accept a nomination to be a committer, and gain CVS access, then
> you can apply your own patches. Since most of use the products we patch,
> this is an important benefit to most contributors. If you happen to see
> a patch from another contributor that you think is useful, you can apply
> that too. But none of us are obligated to do anything we don't want to
> do.

That will attract volunteers a great deal ;((.
The least "the project" (and therefor also you as a committer), has an
obligation to give a reasonable response to the effort taken. Clouding
the mailinglist with reminders (what some projects actually specifically
ask for), is actually not something I should invest my time in. 
Just a simple "we don't have time for it now, it is on the todo list..
", would do in many cases. 

So if you don't want to take that effort  : don't take up the
responsibility of being a committer. 

So the obligation to do something with it, is of the project and if you
are part of that you have an obligation. 

Mvgr,
Martin




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Ted Husted <hu...@apache.org>.
I believe the fundamental principal behind our system is 

	Them that does the work makes the decisions. 

Integrating code or documentation into CVS is work, and people who do
that work are entitled to be decision-makers. 

I believe a secondary principal behind our system is 

	Thanks for volunteering.

If you think something needs to be done, then you volunteer to do it. 

So, as a committer, you can decide that something needs to be added or
changed, and then you can go ahead and do it. 

Most anything that needs to be done on a product, including the
documentationa and website, involves CVS. Doing and decision-making all
center on CVS. 

If you accept a nomination to be a committer, and gain CVS access, then
you can apply your own patches. Since most of use the products we patch,
this is an important benefit to most contributors. If you happen to see
a patch from another contributor that you think is useful, you can apply
that too. But none of us are obligated to do anything we don't want to
do.

If there are other ways to contribute to a product that don't involve
CVS, and the Committers to a product want to make someone a Committer in
recognition of their non-CVS contributions, that sounds fine to me. Just
because you have CVS access doesn't mean you have to use it. 

It's fun to talk about the obligations and responsibilites of
Committers, but the only real obligation is to commit your own stuff.
(Thanks for volunteering.)

Once someone is a Committer, I would also say that voting and handling
support issues on the lists is participating, and as long as they show
up once in a while to help out, AFAIC, they can keep their Committer
badge. 

So, I'm saying 

+ If you are working hard enough to need CVS access, you are working
hard enough to be a Committer. 
+ If you are making significant contributions to the product in ways
that don't require CVS access, sure, you can be a Committer too.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 5/29/02 1:47 PM, "Andrew C. Oliver" <ac...@apache.org> wrote:

> I got shot down by the POI community.

Sounds like a common thread, eh?

;-)

-jon 


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
Jon Scott Stevens wrote:

>on 5/29/02 7:23 AM, "Andrew C. Oliver" <ac...@apache.org> wrote:
>
>  
>
>>to me the point that Pier was trying to get accross that I agreed with
>>is that there is sometimes work that happens
>>outside of CVS worthy of committership (and/or that should require
>>committership) irrelevant of CVS access.
>>    
>>
>
>Yea, like that code that will auto-format your code on checkin that you
>threatened to write a month or so ago...
>
>;-)
>
>-jon (still waiting) stevens
>  
>
Not that it had anything to do with anything but....

I got shot down by the POI community.  They don't want their code 
reformatted.    Check the archives.
I began the proposal with "Any discussion regarding bracket placement 
automatically kills this proposal and
it shall be hereby recended"...

-Andy

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




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 5/29/02 7:23 AM, "Andrew C. Oliver" <ac...@apache.org> wrote:

> to me the point that Pier was trying to get accross that I agreed with
> is that there is sometimes work that happens
> outside of CVS worthy of committership (and/or that should require
> committership) irrelevant of CVS access.

Yea, like that code that will auto-format your code on checkin that you
threatened to write a month or so ago...

;-)

-jon (still waiting) stevens


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
Nicola Ken Barozzi wrote:

>From: "Leo Simons" <le...@apache.org>
>
>  
>
>>On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
>>    
>>
>>> I don't think
>>>there is anything to forbid a community from temporarily granting CVS
>>>access.
>>>      
>>>
>>;)
>>
>>Well, I think our guidelines forbid us. You cannot give someone CVS
>>access without giving them all the committer rights and responsibilities
>>as well. That's the point of the discussion, innit?
>>    
>>
>
>Yes, it is.
>
>I regard CVS as the heart of our system.
>
to me the point that Pier was trying to get accross that I agreed with 
is that there is sometimes work that happens
outside of CVS worthy of committership (and/or that should require 
committership) irrelevant of CVS access.

>Would you make a well known surgeon operate your heart without knowing him
>first, and being sure he can assist you afterwards?
>If you do, usually it's for emergencies... like wanting some 20MB patch to
>be in CVS and not having time to do it.
>  
>
>Personally, I would prefer not have the patch at all, if it means giving
>access to the CVS to someone you don't trust.
>And if you trust him, there is no time limit.
>Nothing prevents him from asking his account to be deleted anyway.
>  
>
Agreed.

>If you invite someone in the boat with you, it's because you think that
>he'll be part of the group, and share roles and responsibilities; I don't
>think we need technical "repairmen" here.
>I may be wrong, but for me it's a matter of trust, personal trust.
>  
>
Agreed.

>I have been contributing stuff to Cocoon since version 1.7, but never
>proposed as a comitter.
>Why?
>Because I wasn't ready for OS collaboration, and they didn't trust me.
>
>This made me stronger, and I learned a lot.
>Now you made me come in Avalon just on my word and good proposition, and
>this is something I will never forget. It has a very strong meaning for me.
>
>I would like that others have these possibilities, that have made me learn a
>lot.
>I'm afraid that having "technitians" would break up this system.
>  
>
Well spoken!

>--
>Nicola Ken Barozzi                   nicolaken@apache.org
>            - verba volant, scripta manent -
>   (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
> > On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
> > >  I don't think
> > > there is anything to forbid a community from temporarily granting CVS
> > > access.
> >
> > ;)
> >
> > Well, I think our guidelines forbid us. You cannot give someone CVS
> > access without giving them all the committer rights and responsibilities
> > as well. That's the point of the discussion, innit?
> 
> Yes, it is.
> 
> I regard CVS as the heart of our system.
> Would you make a well known surgeon operate your heart without knowing him
> first, and being sure he can assist you afterwards?

This is somewhat different - no lives are at stake, the "operation" can
be reversed, etc etc.

> Personally, I would prefer not have the patch at all, if it means giving
> access to the CVS to someone you don't trust.
> And if you trust him, there is no time limit.
> Nothing prevents him from asking his account to be deleted anyway.
> 
> If you invite someone in the boat with you, it's because you think that
> he'll be part of the group, and share roles and responsibilities; I don't
> think we need technical "repairmen" here.
> I may be wrong, but for me it's a matter of trust, personal trust.

don't let a bad example get in the way of the general idea. You should
trust this person, and he should trust you. Making him a committer is
not the only way to express this trust.

> I have been contributing stuff to Cocoon since version 1.7, but never
> proposed as a comitter.
> Why?
> Because I wasn't ready for OS collaboration, and they didn't trust me.
> 
> This made me stronger, and I learned a lot.
> Now you made me come in Avalon just on my word and good proposition, and
> this is something I will never forget. It has a very strong meaning for me.

I can totally relate to that story...I probably wouldn't be here if I
hadn't, at one time, been welcomed in the same way.

> 
> I would like that others have these possibilities, that have made me learn a
> lot.
> I'm afraid that having "technitians" would break up this system.

You mean being proposed and accepting to be a "technitian" reduces
educational value for beginning OSS developers and reduces the drive for
them of becoming committers later?

that might just be true.

cheers,

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Leo Simons" <le...@apache.org>

> On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
> >  I don't think
> > there is anything to forbid a community from temporarily granting CVS
> > access.
>
> ;)
>
> Well, I think our guidelines forbid us. You cannot give someone CVS
> access without giving them all the committer rights and responsibilities
> as well. That's the point of the discussion, innit?

Yes, it is.

I regard CVS as the heart of our system.
Would you make a well known surgeon operate your heart without knowing him
first, and being sure he can assist you afterwards?
If you do, usually it's for emergencies... like wanting some 20MB patch to
be in CVS and not having time to do it.

Personally, I would prefer not have the patch at all, if it means giving
access to the CVS to someone you don't trust.
And if you trust him, there is no time limit.
Nothing prevents him from asking his account to be deleted anyway.

If you invite someone in the boat with you, it's because you think that
he'll be part of the group, and share roles and responsibilities; I don't
think we need technical "repairmen" here.
I may be wrong, but for me it's a matter of trust, personal trust.

I have been contributing stuff to Cocoon since version 1.7, but never
proposed as a comitter.
Why?
Because I wasn't ready for OS collaboration, and they didn't trust me.

This made me stronger, and I learned a lot.
Now you made me come in Avalon just on my word and good proposition, and
this is something I will never forget. It has a very strong meaning for me.

I would like that others have these possibilities, that have made me learn a
lot.
I'm afraid that having "technitians" would break up this system.

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>  
>
>>>"Why is increased granularity in role/right/responsibility bad in
>>>general?"
>>>
>>>      
>>>
>>1. Because it is a cop out.  
>>    
>>
>
>http://www.dictionary.com/search?q=cop%20out (I'm learning today =)
>
>which one do you mean?
>  
>
/**/
To avoid fulfilling a commitment or responsibility; renege: copped out 
on my friends; copped out by ducking the issue.

>  
>
>>2. If this is about community and not code then we want participating 
>>members in the community
>>    
>>
>
>don't follow...you mean limited community participating should not be an
>option if you want right X?
>  
>
Yes.

>  
>
>>3. "granularity" is a clever way of putting it, but thats not what this 
>>is about
>>    
>>
>
>I think there's a close relationship. You could also talk about
>decoupling, as Pier coined it, leading to:
>
>"Why is decoupling sets of rights/responsibilities from each other a bad
>thing?"
>
>Note that doing so would lead to an increase in "roles", ie a more
>granular system. Just my view of the world...
>  
>
No I think bestowing "committership" on people who have CVS-Like access 
(shell access is an equal amount of trust) is
different from bestowing committership without voting rights/etc.

>  
>
>>4. "Code dumps" are white elephants
>>    
>>
>
>one does not automatically lead to another. Increased "granularity"
>("right/responsibility set decoupling") doesn't mean an increase in code
>dumps.
>  
>
That was your rationale for this.  

>  
>
>>5. Opening the floodgates to CVS is bad (for so many reasons),
>>    
>>
>
>same as for 4.
>  
>
its still bad.

>  
>
>>6. If you trust them in the repository, you accept their code, then they 
>>should be part of the community,
>>    
>>
>
>yes. But there are various ways of participating in the community. You
>can accept their code and trust them in the repository, and they can be
>a member of the community, and still not be a committer. Well, not now,
>but the thought is to change that.
>  
>
That is a bad idea.

>This is about the specific case of creating a role that provides cvs
>access and no other rights, though.
>  
>
give me a use case other than code dumps.  I see no compelling need for 
this.

>  
>
>>>      
>>>
>>I've explained this sufficiently in this and other emails.
>>    
>>
>
>except I still don't get it =)
>  
>
I don't get why you'd want to effect this change. :-)

>  
>
>> I do not 
>>think defining a role for folks whose work is not CVS-based but just as 
>>relevant if its clearly defined.
>>    
>>
>
>you ment to end with "is stupid/bad" or something, right? On that the
>two of us agree, then? (now for the rest of the world...)
>  
>
sorry I meant to say that non CVS-based "committers" should be 
recognized.  (shell access is just as big of
a trust thing as CVS access if not bigger)

>  
>
>> Overall I'm happy with the 
>>organization as it is and do not think it needs radical social engineering.
>>    
>>
>
>of course. But maintainance is cool.
>  
>
only where needed.

-Andy

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




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
> Pragmatically I think if a community voted to temporarily grant access 
> to its CVS repository, I'll bet it
> could be done.

More than likely...point of discussing it is to try and reach an
agreement about whether it should be done...

> >"Why is increased granularity in role/right/responsibility bad in
> >general?"
> >
> 1. Because it is a cop out.  

http://www.dictionary.com/search?q=cop%20out (I'm learning today =)

which one do you mean?

> 2. If this is about community and not code then we want participating 
> members in the community

don't follow...you mean limited community participating should not be an
option if you want right X?

> 3. "granularity" is a clever way of putting it, but thats not what this 
> is about

I think there's a close relationship. You could also talk about
decoupling, as Pier coined it, leading to:

"Why is decoupling sets of rights/responsibilities from each other a bad
thing?"

Note that doing so would lead to an increase in "roles", ie a more
granular system. Just my view of the world...

> 4. "Code dumps" are white elephants

one does not automatically lead to another. Increased "granularity"
("right/responsibility set decoupling") doesn't mean an increase in code
dumps.

> 5. Opening the floodgates to CVS is bad (for so many reasons),

same as for 4.

> 6. If you trust them in the repository, you accept their code, then they 
> should be part of the community,

yes. But there are various ways of participating in the community. You
can accept their code and trust them in the repository, and they can be
a member of the community, and still not be a committer. Well, not now,
but the thought is to change that.

This is about the specific case of creating a role that provides cvs
access and no other rights, though.

> >"Why is defining a new role that is in between the currently defined
> >roles of contributor and committer in terms of rights and
> >responsibilities a bad thing?"
> >  
> >
> I've explained this sufficiently in this and other emails.

except I still don't get it =)

>  I do not 
> think defining a role for folks whose work is not CVS-based but just as 
> relevant if its clearly defined.

you ment to end with "is stupid/bad" or something, right? On that the
two of us agree, then? (now for the rest of the world...)

>  Overall I'm happy with the 
> organization as it is and do not think it needs radical social engineering.

of course. But maintainance is cool.

cheers,

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>thought that was a special kind of elephant...
>
>http://www.dictionary.com/search?q=white%20elephant
>
>...does now.
>  
>
In some Asian cultures, a particularaly cruel way to blight someone you 
didn't like was to gift them a
white elephant.  They'd need to feed and take care of it because they 
were considered something sacred
and rare -- but an elephant eats a lot....and well outputs a lot as well.

>  
>
>> I don't think
>>there is anything to forbid a community from temporarily granting CVS
>>access.
>>    
>>
>
>;)
>
>Well, I think our guidelines forbid us. You cannot give someone CVS
>access without giving them all the committer rights and responsibilities
>as well. That's the point of the discussion, innit?
>  
>
Pragmatically I think if a community voted to temporarily grant access 
to its CVS repository, I'll bet it
could be done.

>Not going anywhere; I'd rather see an answer to:
>
>"Why is increased granularity in role/right/responsibility bad in
>general?"
>
1. Because it is a cop out.  
2. If this is about community and not code then we want participating 
members in the community
3. "granularity" is a clever way of putting it, but thats not what this 
is about
4. "Code dumps" are white elephants
5. Opening the floodgates to CVS is bad (for so many reasons),
6. If you trust them in the repository, you accept their code, then they 
should be part of the community, otherwise, you shouldn't accept either.

>
>and
>
>"Why is defining a new role that is in between the currently defined
>roles of contributor and committer in terms of rights and
>responsibilities a bad thing?"
>  
>
I've explained this sufficiently in this and other emails.  I do not 
think defining a role for folks whose work is not CVS-based but just as 
relevant if its clearly defined.  Overall I'm happy with the 
organization as it is and do not think it needs radical social engineering.

-Andy


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




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
> 
> > Yeah, exactly. And what if there is someone who actually wants less
> > responsibility and less rights than a committer, but still more than a
> > contributor?
> > 
> 
> -1

why?

> Does the term "white elephant" mean anything to you?

thought that was a special kind of elephant...

http://www.dictionary.com/search?q=white%20elephant

...does now.

>  I don't think
> there is anything to forbid a community from temporarily granting CVS
> access.

;)

Well, I think our guidelines forbid us. You cannot give someone CVS
access without giving them all the committer rights and responsibilities
as well. That's the point of the discussion, innit?

> I would say such a "gift" should not be interpreted with the direct
> meaning of the word in German.  Such things usually are wrought with
> problems and with this person who dumps a bunch of code into your
> repository and leaves, well generally it reduces the quality of your
> codebase and no one who IS part of the community knows the code.

This is of course, generalising, and we're leading away from the
discussion here. I say we should evaluate role/right/responsibility
granularity, you write an example line of thought of a potential
candidate for a new role to illustrate you disagree, so I provide a
"counterexample".

Not going anywhere; I'd rather see an answer to:

"Why is increased granularity in role/right/responsibility bad in
general?"

and

"Why is defining a new role that is in between the currently defined
roles of contributor and committer in terms of rights and
responsibilities a bad thing?"

cheers,

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
> Yeah, exactly. And what if there is someone who actually wants less
> responsibility and less rights than a committer, but still more than a
> contributor?
> 

-1

> It is all about granularity: less rights, less responsibility.
> 
> > "Gee I'd like to dump my code
> > here and not bother with the community"....
> 
> "Gee I've created this amazing forked version of your codebase (this
> amazing book about your project, ..., ...) and now got permission from
> my employer to contribute it back. This is quite a lot of stuff, you can
> find it at http://somewhere/ to look at. If you accept, do you want 20MB
> worth of patches or can you give me CVS access?"
> 
> What if the community would very much like you to provide that stuff,
> you're already committer in other apache projects, but have no time to
> support your submission for longer than, say, a month? Should you be
> committer for a month?
> 

Does the term "white elephant" mean anything to you?  I don't think
there is anything to forbid a community from temporarily granting CVS
access.

I would say such a "gift" should not be interpreted with the direct
meaning of the word in German.  Such things usually are wrought with
problems and with this person who dumps a bunch of code into your
repository and leaves, well generally it reduces the quality of your
codebase and no one who IS part of the community knows the code.


-Andy

> etc etc etc.
> 
> cheers,
> 
> - Leo
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
> > Case can be made that since putting something in CVS is putting
> > something up for lazy majority vote (and I subscribe to that), this is
> > not a good 'use case'. But what is wrong with a role for people that
> > have the option to propose something for a lazy majority vote, and then
> > no right/obligation to actually vote on that 'something' or anything
> > else?
> > 
> 
> I think with rights comes responsibility.

Yeah, exactly. And what if there is someone who actually wants less
responsibility and less rights than a committer, but still more than a
contributor?

It is all about granularity: less rights, less responsibility.

> "Gee I'd like to dump my code
> here and not bother with the community"....

"Gee I've created this amazing forked version of your codebase (this
amazing book about your project, ..., ...) and now got permission from
my employer to contribute it back. This is quite a lot of stuff, you can
find it at http://somewhere/ to look at. If you accept, do you want 20MB
worth of patches or can you give me CVS access?"

What if the community would very much like you to provide that stuff,
you're already committer in other apache projects, but have no time to
support your submission for longer than, say, a month? Should you be
committer for a month?

etc etc etc.

cheers,

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Tue, 2002-05-28 at 17:36, Leo Simons wrote:
> On Tue, 2002-05-28 at 14:20, Andrew C. Oliver wrote:
> > I totally disagree with everything you just said.
> 
> Uhm, I think you disagree with the idea "we should have
> 'developers/contributors' with CVS access who are not committers". I'm
> not sure whether I support that idea yet.
> 
> You also disagree with the other stuff I said?
> 
> > I do NOT think developers should be granted CVS access without voting 
> > rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
> > want to give you the rights to control your work or give you any 
> > ownership in what you do".  If they are frequent enough committers to 
> > require CVS access...then they deserve the rights there under.
> 
> Missing the point I made that there might be people out there that want
> some of the rights that come with committer status, not caring about
> having all of them, while not wanting all of the duties that come with
> committer status.
> 

I want a million dollars with no responsibilities such as paying taxes
or any of that stuff.  With rights come responsibilities, such is life.

> Heck, I'll probably submit more than a few patches to centipede in the
> future; people will probably get tired of applying them and they might
> ask me to become a committer, to which I will say "no thanks" as I feel
> I have have no time to make that commitment. It'll still be easier for
> both the committers and me if I still get CVS access.
> 

Centipede is not a Jakarta project, and if the voting rules for
centipede are documented, I missed the link.  I think for the moment its
either common law or "understood" because nearly everyone there is a
committer on some Apache project somewhere.  

> I'm not saying we should allow it, just that there's two sides to the
> story.
> 

I'd in fact -1 the idea of giving you CVS access without agreeing to be
a committer.

Krysalis (from what I can tell) actually has a slightly different type
of committership.  One is a committer to all projects (meaning I get to
vote on Wings and Centipede both).

I think I may be (there) an excellent example of the type of "committer"
that Pier talks about.  I've actually committed 0 code to Wings or
Centipede.  All of my work has been in setup, publicising, cross
OS-testing, and well lots of little things that aren't code but that
well the project might not be where it is today had I not done them.  

> Case can be made that since putting something in CVS is putting
> something up for lazy majority vote (and I subscribe to that), this is
> not a good 'use case'. But what is wrong with a role for people that
> have the option to propose something for a lazy majority vote, and then
> no right/obligation to actually vote on that 'something' or anything
> else?
> 

I think with rights comes responsibility.  "Gee I'd like to dump my code
here and not bother with the community".... I want a million dollars
without bothering with earning it or the taxes or jailtime or
whatever...

-Andy

> g'night,
> 
> - Leo
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-05-28 at 14:20, Andrew C. Oliver wrote:
> I totally disagree with everything you just said.

Uhm, I think you disagree with the idea "we should have
'developers/contributors' with CVS access who are not committers". I'm
not sure whether I support that idea yet.

You also disagree with the other stuff I said?

> I do NOT think developers should be granted CVS access without voting 
> rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
> want to give you the rights to control your work or give you any 
> ownership in what you do".  If they are frequent enough committers to 
> require CVS access...then they deserve the rights there under.

Missing the point I made that there might be people out there that want
some of the rights that come with committer status, not caring about
having all of them, while not wanting all of the duties that come with
committer status.

Heck, I'll probably submit more than a few patches to centipede in the
future; people will probably get tired of applying them and they might
ask me to become a committer, to which I will say "no thanks" as I feel
I have have no time to make that commitment. It'll still be easier for
both the committers and me if I still get CVS access.

I'm not saying we should allow it, just that there's two sides to the
story.

Case can be made that since putting something in CVS is putting
something up for lazy majority vote (and I subscribe to that), this is
not a good 'use case'. But what is wrong with a role for people that
have the option to propose something for a lazy majority vote, and then
no right/obligation to actually vote on that 'something' or anything
else?

g'night,

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
I totally disagree with everything you just said.  I think "committer" 
status should be granted to folks who do *other* things outside of CVS. 
 But the key word is "Do".  So pretend for a second that Pier is *not 
otherwise* a comitter to Tomcat and wherever, he does a lot of other 
stuff like manage bugzilla.  And bugzilla...what a pain.  So I would say 
Pier should be granted some voting rights etc.  I think thats the goal 
here and I agree with to goal, but none of the proposals I've seen spell 
out tight enough constraints.  

I do NOT think developers should be granted CVS access without voting 
rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
want to give you the rights to control your work or give you any 
ownership in what you do".  If they are frequent enough committers to 
require CVS access...then they deserve the rights there under.

-Andy

Leo Simons wrote:

>>Since this is a volunteer organization, and we all have other pressing
>>responsibilities, it is important that we do not encourage any systemic
>>bottlenecks.
>>    
>>
>
>I wrote:
>"> > user: no rights, no responsibilities
>  
>
>>>developer: right to get quoted as author for authored pieces, no
>>>responsibility
>>>committer: right to vote as per voting guidelines, responsibility to
>>>sign and submit Contributor License Agreement
>>>pmc member: right and obligation to set overall project direction"
>>>      
>>>
>
>this is not quite reflective of our current situation. The term
>"developer" can sometimes be misleading ("contributor" would be better,
>perhaps), while "committer" perhaps should include some added guidelines
>wrt responsibilities.
>
>You might call the fact that these definitions are somewhat out of whack
>a "systemic bottleneck".
>
>  
>
>>Since committing is voting, what I think what some people want is a
>>non-vetoing Committer.
>>    
>>
>
>I think 'some people' don't see/don't agree to the "committing is
>voting", and then what they want is a Developer-with-CVS-access, which
>is more or less what they said.
>
>"Committing is voting" is not reflected in our guidelines (at least I
>couldn't find such a notion).
>
>  
>
>>Someone to do the work without sharing in the
>>responsibility.
>>    
>>
>
>sounds like what we call "developer" in our guidelines ;)
>
>  
>
>>Which is to say, we can reject what they do, but they
>>can't reject what we do. Personally, I would find that type of
>>master/slave relationship difficult to maintain in a volunteer 
>>organization like this. If you are working hard enough to need commit 
>>rights, you are working hard enough to have veto rights. 
>>    
>>
>
>What if someone wants/needs commit rights but doesn't want the veto
>rights (and responsibilities)? The right to vote also means an
>obligation to vote/abstain. The implication of your statement is "if you
>are given cvs access, you should also take on the responsibility of
>voting".
>
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>




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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
> Since this is a volunteer organization, and we all have other pressing
> responsibilities, it is important that we do not encourage any systemic
> bottlenecks.

I wrote:
"> > user: no rights, no responsibilities
> > developer: right to get quoted as author for authored pieces, no
> > responsibility
> > committer: right to vote as per voting guidelines, responsibility to
> > sign and submit Contributor License Agreement
> > pmc member: right and obligation to set overall project direction"

this is not quite reflective of our current situation. The term
"developer" can sometimes be misleading ("contributor" would be better,
perhaps), while "committer" perhaps should include some added guidelines
wrt responsibilities.

You might call the fact that these definitions are somewhat out of whack
a "systemic bottleneck".

> Since committing is voting, what I think what some people want is a
> non-vetoing Committer.

I think 'some people' don't see/don't agree to the "committing is
voting", and then what they want is a Developer-with-CVS-access, which
is more or less what they said.

"Committing is voting" is not reflected in our guidelines (at least I
couldn't find such a notion).

> Someone to do the work without sharing in the
> responsibility.

sounds like what we call "developer" in our guidelines ;)

> Which is to say, we can reject what they do, but they
> can't reject what we do. Personally, I would find that type of
> master/slave relationship difficult to maintain in a volunteer 
> organization like this. If you are working hard enough to need commit 
> rights, you are working hard enough to have veto rights. 

What if someone wants/needs commit rights but doesn't want the veto
rights (and responsibilities)? The right to vote also means an
obligation to vote/abstain. The implication of your statement is "if you
are given cvs access, you should also take on the responsibility of
voting".

cheers,

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Ted Husted <hu...@apache.org>.
I think the real point is that while, given the chance, some people may
prefer to do one thing or another, as Committers we all can potentially
do anything that needs to be done whenever we have time to do it. 

Since this is a volunteer organization, and we all have other pressing
responsibilities, it is important that we do not encourage any systemic
bottlenecks. If the Committer who likes to do the releases can't,
someone else can just step up to bat without any hoopla. A committer is
a committer .. from each according to their abilities, to each according
to their needs. 

Regardless of what we choose to do from time to time, the codebase is
our joint responsiblity. And when we drift away, someone else will step
into our shoes. When we are gone, another committer may elect to do what
we used to do, or a new contributor may fill the void and then be 
nominated as the product's newest Committer. 

The real problem I would have with non-voting Committers is that
comitting is an important way of how we vote. Because we are all
responsible for the entire codebase, jointly and severally, we don't 
have to vote on every little thing. We can vote through our commits -- 
unless and until another Committer points out an error in our judgment. 

Since committing is voting, what I think what some people want is a
non-vetoing Committer. Someone to do the work without sharing in the
responsibility. Which is to say, we can reject what they do, but they
can't reject what we do. Personally, I would find that type of
master/slave relationship difficult to maintain in a volunteer 
organization like this. If you are working hard enough to need commit 
rights, you are working hard enough to have veto rights. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Leo Simons wrote:
> we have, in practice, in quite a few of the subprojects. The "in
> practice" part in that sentence explains the quotes around "leads".
> 
> We have a nice theoretical meritocracy model defining several "roles and
> responsibilities". That's just fine. The current model defines "user",
> "developer", "committer" and "pmc member".
> 
> In real life, there's more roles, overlapping roles, more specific
> roles, less specific roles.
> 
> Examples: with Avalon, Peter and Berin handle most of our releases; they
> assume the role of "release manager". Jeff Turner's been working on the
> build process; he had the cap of "build process manager", now passed
> over to Nicola Ken, all informally.
> 
> Fortunately, this is all okay and no-one complains. Like Ted said, we're
> pragmatic about it.
> 
> Thing is, formal roles and responsibilities currently are
> (as per http://jakarta.apache.org/site/roles.html):
> 
> user: no rights, no responsibilities
> developer: right to get quoted as author for authored pieces, no
> responsibility
> committer: right to vote as per voting guidelines, responsibility to
> sign and submit Contributor License Agreement
> pmc member: right and obligation to set overall project direction
> 
> when these no longer reflect the ad hoc pragmatic roles defined within
> subprojects, or when they make using these pragmatic "roles" difficult,
> we should think about changing these definitions, roles and
> responsibilities.
> 
> Fact of the matter is, the model is not perfect, and not everyone in our
> community fits into these categories very well. Saying that everyone who
> submits a patch is a developer is a bit of a strange definition, as you
> don't really "develop" documentation, etc etc etc.
> 
> Pier brings this up, perhaps in a somewhat clumsy way, but with a valid
> point and valid arguments: voila, heated discussion and comments on a
> personal note.
> 
> "if it ain't broken, don't fix it" leads to things like windows. We'd
> still be forced to work with AWT and JSP.
> 
> - Leo

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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Leo Simons <le...@apache.org>.
> > + some mailing list management software + some product release software) it 
> > would be very beneficial to push the administration down onto project "leads" 
> 
> So we'll also have 'project leads' ? 
>
> And some people who write and maintain code, but have different rights ?

we have, in practice, in quite a few of the subprojects. The "in
practice" part in that sentence explains the quotes around "leads".

We have a nice theoretical meritocracy model defining several "roles and
responsibilities". That's just fine. The current model defines "user",
"developer", "committer" and "pmc member".

In real life, there's more roles, overlapping roles, more specific
roles, less specific roles.

Examples: with Avalon, Peter and Berin handle most of our releases; they
assume the role of "release manager". Jeff Turner's been working on the
build process; he had the cap of "build process manager", now passed
over to Nicola Ken, all informally.

Fortunately, this is all okay and no-one complains. Like Ted said, we're
pragmatic about it.

Thing is, formal roles and responsibilities currently are
(as per http://jakarta.apache.org/site/roles.html):

user: no rights, no responsibilities
developer: right to get quoted as author for authored pieces, no
responsibility
committer: right to vote as per voting guidelines, responsibility to
sign and submit Contributor License Agreement
pmc member: right and obligation to set overall project direction

when these no longer reflect the ad hoc pragmatic roles defined within
subprojects, or when they make using these pragmatic "roles" difficult,
we should think about changing these definitions, roles and
responsibilities.

Fact of the matter is, the model is not perfect, and not everyone in our
community fits into these categories very well. Saying that everyone who
submits a patch is a developer is a bit of a strange definition, as you
don't really "develop" documentation, etc etc etc.

Pier brings this up, perhaps in a somewhat clumsy way, but with a valid
point and valid arguments: voila, heated discussion and comments on a
personal note.

"if it ain't broken, don't fix it" leads to things like windows. We'd
still be forced to work with AWT and JSP.

- Leo



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Peter Donald <pe...@apache.org>.
On Tue, 28 May 2002 03:12, costinm@covalent.net wrote:
> On Sun, 26 May 2002, Peter Donald wrote:
> > + some mailing list management software + some product release software)
> > it would be very beneficial to push the administration down onto project
> > "leads"
>
> So we'll also have 'project leads' ?

we already do in practice. Some projects more so than others. As been stated 
before - Apache is a meritocracy, the more you contribute, the more 
responsibility and power you receive.

-- 
Cheers,

Peter Donald



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sun, 26 May 2002, Peter Donald wrote:

> + some mailing list management software + some product release software) it 
> would be very beneficial to push the administration down onto project "leads" 

So we'll also have 'project leads' ? 

And some people who write and maintain code, but have different rights ?

Costin


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Peter Donald <pe...@apache.org>.
Hi,

I would love to be able to give people partiial access to projects and I would 
also love to expire accounts if they are dormant or the person goes MIA.

For instance the first one would be especially useful in projects like ant, 
excalibur and commons. Many times in ant the committers have wanted to give a 
person access to a certain subtree in CVS because they contributed it and 
would be able to maintain it. ie Originally the Perforce tasks in Ant were 
largely contributed by a single individual and it would have been great if 
that person coul ddirectly maintain them.

However given that every new committer needs a new account on the boxen we 
never moved forward on it. When more appropriate infrastructure is put in 
place (Subversion - rah rah rah! Subversion - rah rah rah!) I think it would 
definetly be a good idea to do that. However that may put too big a burden on 
the system admins. 

When the new infrastructure is in place (think subversion, eyebrowse, scarab, 
+ some mailing list management software + some product release software) it 
would be very beneficial to push the administration down onto project "leads" 
and away from sys admins (who are prolly overloaded anyways). No one besides 
a select few would even need accounts.

Of course this needs a lot of volunteers to get started but until then I am 
not sure it would be possible to please everyone. However when thats in place 
all projects effectively manage themselves as they see fit.

On Sat, 25 May 2002 09:06, Pier Fumagalli wrote:
> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
>
> So the major topic of discussion is that I perceive a substantial
> difference between being able to commit code to a CVS repository, and being
> a "committer" committer, with all dues and responsibilities that this role
> concerns...
>
> For example sometimes someone might want to have commit access just because
> he is working for a company that deals with a particular project in Apache
> (we've seen this happening several times with some projects such as Xerces
> and Tomcat), but he really doesn't care about the whole fuzz of Apache and
> stuff, and once the employment contract ends, the relationship with Apache
> terminates as well (I don't need to enumerate all those examples along
> those lines).
>
> One other example, if we didn't have Henri building RPMs for basically all
> Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> don't you think that he would deserve committer status even if he's not
> tied to any particular codebase? We had this "problem" in the current
> election of the members, Sally Khudairi: Sally doesn't code, but she was
> involved with the ASF since before it was even created as a press
> organizer. Does she deserve to be a member of the foundation? Even if she
> doesn't code? Yes she does, IMO (and she was elected and nominated a member
> today)...
>
> So, IMO, there's a great difference between being a coder, and being a
> member of the Jakarta community, at least in my opinion. There might be
> coders who are not involved with the community, and there might be
> non-coders who are much involved with it, want to participate, are active
> and deserve to be committers...
>
> Our current structure doesn't "allow" that to happen, both things. If you
> need to write code in a particular source-base, and you need CVS access,
> you are automagically made a committer, even if you don't care about much
> else, and if you're very much involved with the overall project, but not
> tied to ANY whatsoever codebase, and really, don't want / can't do it.
>
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the
> "committer" figure in two parts:
>
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
>
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
>
> And redefining the figure of the "committer" as follows:
>
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking
> the code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
>
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?
>
>     Pier

-- 
Cheers,

Peter Donald


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sun, 2002-05-26 at 14:15, Nicola Ken Barozzi wrote:
> Well said.
> I subscribe to this.
> 
> We should remember that people that contribute so much should be proposed as
> committers, regardless to the code submitted, as is done AFAIK in POI,
> Struts, Cocoon, Forrest, Avalon, and the Krysalis projects (that refer to
> Apache guidelines).
> 

I dunno, I think there is a point... I would probably be reluctant to
ask for CVS access for someone whom I did not trust could use it
properly, but I think we'd still vote them a committer....then again I'd
-1 anyone being a committer who I didn't think had the good sense not to
play in CVS if they didn't know what they were doing...so its probably
moot.  

-Andy

> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: "Jakarta General List" <ge...@jakarta.apache.org>
> Sent: Sunday, May 26, 2002 6:59 PM
> Subject: Re: [PROPOSAL] Committer access and responsibilities...
> 
> 
> > Those who do the work of creating a Jakarta product are entitled to make
> > the decisions regarding that product. A successful product is more than
> > code, it also requires documentation and support and easy-to-use
> > distributions.
> >
> > Whether a patch is to the code or the documentation isn't relevant. A
> > patch is a patch, a contribution is a contribution, and anyone who
> > makes sustained contributions to a product is elligible to become a
> > committer.
> >
> > A change to the codebase can affect everyone, including them that don't
> > code but "simply" document. They should have as much to say about the
> > codebase as everyone else.
> >
> > The real point behind meritocracy, I believe, is that we are all equal
> > and there is no formal hierarchy. It's also a big part of what
> > makes Jakarta both fun and different from our regular jobs.
> >
> > We have a simple and effective system here that's been proven to work.
> > I don't believe that the formal system is broken or needs to be
> > refactored.
> >
> > -1 on there being shades of gray between contributors and committers.
> >
> > A contributor is anyone who has submitted code, documentation or
> > any other deliverable that has been made part of the product.
> > Committers do the work of creating the product by posting
> > contributions to the CVS or other secure area.
> >
> > +1 on "non-coders" or "specialists" being voted as committers when
> > the circumstances warrant. There is nothing to prevent this now
> > nor should there ever be. If its OK with the other committers to a
> > product, there's no reason for the rest of us to care. If it's not
> > OK with the other committers, then it is not the system that's
> > broken, but the committers -- and no amount of tinkering is going
> > to fix that.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY US
> > -- Developing Java Web Applications with Struts
> > -- Tel: +1 585 737-3463
> > -- Web: http://husted.com/about/services
> >
> >
> >
> > Pier Fumagalli wrote:
> > >
> > > Chatted with a lot of people, seen many, different development models,
> went
> > > around, asked, talked, and I believe I have a pretty decent picture, and
> > > maybe even a solution...
> > >
> > > So the major topic of discussion is that I perceive a substantial
> difference
> > > between being able to commit code to a CVS repository, and being a
> > > "committer" committer, with all dues and responsibilities that this role
> > > concerns...
> > >
> > > For example sometimes someone might want to have commit access just
> because
> > > he is working for a company that deals with a particular project in
> Apache
> > > (we've seen this happening several times with some projects such as
> Xerces
> > > and Tomcat), but he really doesn't care about the whole fuzz of Apache
> and
> > > stuff, and once the employment contract ends, the relationship with
> Apache
> > > terminates as well (I don't need to enumerate all those examples along
> those
> > > lines).
> > >
> > > One other example, if we didn't have Henri building RPMs for basically
> all
> > > Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> > > don't you think that he would deserve committer status even if he's not
> tied
> > > to any particular codebase? We had this "problem" in the current
> election of
> > > the members, Sally Khudairi: Sally doesn't code, but she was involved
> with
> > > the ASF since before it was even created as a press organizer. Does she
> > > deserve to be a member of the foundation? Even if she doesn't code? Yes
> she
> > > does, IMO (and she was elected and nominated a member today)...
> > >
> > > So, IMO, there's a great difference between being a coder, and being a
> > > member of the Jakarta community, at least in my opinion. There might be
> > > coders who are not involved with the community, and there might be
> > > non-coders who are much involved with it, want to participate, are
> active
> > > and deserve to be committers...
> > >
> > > Our current structure doesn't "allow" that to happen, both things. If
> you
> > > need to write code in a particular source-base, and you need CVS access,
> you
> > > are automagically made a committer, even if you don't care about much
> else,
> > > and if you're very much involved with the overall project, but not tied
> to
> > > ANY whatsoever codebase, and really, don't want / can't do it.
> > >
> > > So, given this little background, I would like to ask to the PMC, and
> all
> > > other committers, if others agree that we should "splitting" the
> "committer"
> > > figure in two parts:
> > >
> > > - contributor: a contributor is someone who has access to a particular
> CVS
> > > tree, but for any reason doesn't want/need to be involved with the whole
> > > Jakarta community. He just wants to code his little bit and live a long
> > > life.
> > >
> > > - member: is someone who is involved with the Jakarta community,
> somehow,
> > > somewhere (might be just giving a great deal in supporting users of our
> > > projects, or providing extra value to projects, like guidance in respect
> to
> > > overall specifications, binary builds). He is effectively a member of
> the
> > > community and has all the rights and dues of every member, such as
> > > participate in the election of the PMC.
> > >
> > > And redefining the figure of the "committer" as follows:
> > >
> > > - committer: is a contributor, but also a member, therefore he has all
> the
> > > privileges and dues of a contributor (having CVS access, and overlooking
> the
> > > code he's contributing to) and of a member (can vote for PMCs, should
> > > participate and contribute to discussions on the overall structure of
> > > Jakarta).
> > >
> > > I believe this makes sense, more sense than what we have now, also
> because
> > > we've seen that happening in the ASF for the very first time with a
> > > non-coding member. Comments please?
> > >
> > >     Pier
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
Well said.
I subscribe to this.

We should remember that people that contribute so much should be proposed as
committers, regardless to the code submitted, as is done AFAIK in POI,
Struts, Cocoon, Forrest, Avalon, and the Krysalis projects (that refer to
Apache guidelines).

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Sent: Sunday, May 26, 2002 6:59 PM
Subject: Re: [PROPOSAL] Committer access and responsibilities...


> Those who do the work of creating a Jakarta product are entitled to make
> the decisions regarding that product. A successful product is more than
> code, it also requires documentation and support and easy-to-use
> distributions.
>
> Whether a patch is to the code or the documentation isn't relevant. A
> patch is a patch, a contribution is a contribution, and anyone who
> makes sustained contributions to a product is elligible to become a
> committer.
>
> A change to the codebase can affect everyone, including them that don't
> code but "simply" document. They should have as much to say about the
> codebase as everyone else.
>
> The real point behind meritocracy, I believe, is that we are all equal
> and there is no formal hierarchy. It's also a big part of what
> makes Jakarta both fun and different from our regular jobs.
>
> We have a simple and effective system here that's been proven to work.
> I don't believe that the formal system is broken or needs to be
> refactored.
>
> -1 on there being shades of gray between contributors and committers.
>
> A contributor is anyone who has submitted code, documentation or
> any other deliverable that has been made part of the product.
> Committers do the work of creating the product by posting
> contributions to the CVS or other secure area.
>
> +1 on "non-coders" or "specialists" being voted as committers when
> the circumstances warrant. There is nothing to prevent this now
> nor should there ever be. If its OK with the other committers to a
> product, there's no reason for the rest of us to care. If it's not
> OK with the other committers, then it is not the system that's
> broken, but the committers -- and no amount of tinkering is going
> to fix that.
>
> -- Ted Husted, Husted dot Com, Fairport NY US
> -- Developing Java Web Applications with Struts
> -- Tel: +1 585 737-3463
> -- Web: http://husted.com/about/services
>
>
>
> Pier Fumagalli wrote:
> >
> > Chatted with a lot of people, seen many, different development models,
went
> > around, asked, talked, and I believe I have a pretty decent picture, and
> > maybe even a solution...
> >
> > So the major topic of discussion is that I perceive a substantial
difference
> > between being able to commit code to a CVS repository, and being a
> > "committer" committer, with all dues and responsibilities that this role
> > concerns...
> >
> > For example sometimes someone might want to have commit access just
because
> > he is working for a company that deals with a particular project in
Apache
> > (we've seen this happening several times with some projects such as
Xerces
> > and Tomcat), but he really doesn't care about the whole fuzz of Apache
and
> > stuff, and once the employment contract ends, the relationship with
Apache
> > terminates as well (I don't need to enumerate all those examples along
those
> > lines).
> >
> > One other example, if we didn't have Henri building RPMs for basically
all
> > Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> > don't you think that he would deserve committer status even if he's not
tied
> > to any particular codebase? We had this "problem" in the current
election of
> > the members, Sally Khudairi: Sally doesn't code, but she was involved
with
> > the ASF since before it was even created as a press organizer. Does she
> > deserve to be a member of the foundation? Even if she doesn't code? Yes
she
> > does, IMO (and she was elected and nominated a member today)...
> >
> > So, IMO, there's a great difference between being a coder, and being a
> > member of the Jakarta community, at least in my opinion. There might be
> > coders who are not involved with the community, and there might be
> > non-coders who are much involved with it, want to participate, are
active
> > and deserve to be committers...
> >
> > Our current structure doesn't "allow" that to happen, both things. If
you
> > need to write code in a particular source-base, and you need CVS access,
you
> > are automagically made a committer, even if you don't care about much
else,
> > and if you're very much involved with the overall project, but not tied
to
> > ANY whatsoever codebase, and really, don't want / can't do it.
> >
> > So, given this little background, I would like to ask to the PMC, and
all
> > other committers, if others agree that we should "splitting" the
"committer"
> > figure in two parts:
> >
> > - contributor: a contributor is someone who has access to a particular
CVS
> > tree, but for any reason doesn't want/need to be involved with the whole
> > Jakarta community. He just wants to code his little bit and live a long
> > life.
> >
> > - member: is someone who is involved with the Jakarta community,
somehow,
> > somewhere (might be just giving a great deal in supporting users of our
> > projects, or providing extra value to projects, like guidance in respect
to
> > overall specifications, binary builds). He is effectively a member of
the
> > community and has all the rights and dues of every member, such as
> > participate in the election of the PMC.
> >
> > And redefining the figure of the "committer" as follows:
> >
> > - committer: is a contributor, but also a member, therefore he has all
the
> > privileges and dues of a contributor (having CVS access, and overlooking
the
> > code he's contributing to) and of a member (can vote for PMCs, should
> > participate and contribute to discussions on the overall structure of
> > Jakarta).
> >
> > I believe this makes sense, more sense than what we have now, also
because
> > we've seen that happening in the ASF for the very first time with a
> > non-coding member. Comments please?
> >
> >     Pier
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Ted Husted <hu...@apache.org>.
Those who do the work of creating a Jakarta product are entitled to make 
the decisions regarding that product. A successful product is more than 
code, it also requires documentation and support and easy-to-use 
distributions. 

Whether a patch is to the code or the documentation isn't relevant. A 
patch is a patch, a contribution is a contribution, and anyone who 
makes sustained contributions to a product is elligible to become a 
committer. 

A change to the codebase can affect everyone, including them that don't
code but "simply" document. They should have as much to say about the
codebase as everyone else. 

The real point behind meritocracy, I believe, is that we are all equal
and there is no formal hierarchy. It's also a big part of what 
makes Jakarta both fun and different from our regular jobs. 

We have a simple and effective system here that's been proven to work. 
I don't believe that the formal system is broken or needs to be 
refactored.

-1 on there being shades of gray between contributors and committers. 

A contributor is anyone who has submitted code, documentation or 
any other deliverable that has been made part of the product. 
Committers do the work of creating the product by posting 
contributions to the CVS or other secure area. 

+1 on "non-coders" or "specialists" being voted as committers when 
the circumstances warrant. There is nothing to prevent this now 
nor should there ever be. If its OK with the other committers to a 
product, there's no reason for the rest of us to care. If it's not 
OK with the other committers, then it is not the system that's 
broken, but the committers -- and no amount of tinkering is going 
to fix that.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services



Pier Fumagalli wrote:
> 
> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
> 
> So the major topic of discussion is that I perceive a substantial difference
> between being able to commit code to a CVS repository, and being a
> "committer" committer, with all dues and responsibilities that this role
> concerns...
> 
> For example sometimes someone might want to have commit access just because
> he is working for a company that deals with a particular project in Apache
> (we've seen this happening several times with some projects such as Xerces
> and Tomcat), but he really doesn't care about the whole fuzz of Apache and
> stuff, and once the employment contract ends, the relationship with Apache
> terminates as well (I don't need to enumerate all those examples along those
> lines).
> 
> One other example, if we didn't have Henri building RPMs for basically all
> Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> don't you think that he would deserve committer status even if he's not tied
> to any particular codebase? We had this "problem" in the current election of
> the members, Sally Khudairi: Sally doesn't code, but she was involved with
> the ASF since before it was even created as a press organizer. Does she
> deserve to be a member of the foundation? Even if she doesn't code? Yes she
> does, IMO (and she was elected and nominated a member today)...
> 
> So, IMO, there's a great difference between being a coder, and being a
> member of the Jakarta community, at least in my opinion. There might be
> coders who are not involved with the community, and there might be
> non-coders who are much involved with it, want to participate, are active
> and deserve to be committers...
> 
> Our current structure doesn't "allow" that to happen, both things. If you
> need to write code in a particular source-base, and you need CVS access, you
> are automagically made a committer, even if you don't care about much else,
> and if you're very much involved with the overall project, but not tied to
> ANY whatsoever codebase, and really, don't want / can't do it.
> 
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
> 
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
> 
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
> 
> And redefining the figure of the "committer" as follows:
> 
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
> 
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?
> 
>     Pier
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

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


RE: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
> But Pier, it doesn't address your original problem though, does it?
> Which was about the "bar height", or how to encourage contributors, and
> increase the number of contributors without diluting, and clogging up, the
> community and decision making processes.
> 

Total and complete agreement.  Well said Sir.

-Andy

> d.
> 
> > - committer: is a contributor, but also a member, therefore he has all the
> > privileges and dues of a contributor (having CVS access, and
> > overlooking the
> > code he's contributing to) and of a member (can vote for PMCs, should
> > participate and contribute to discussions on the overall structure of
> > Jakarta).
> >
> > I believe this makes sense, more sense than what we have now, also because
> > we've seen that happening in the ASF for the very first time with a
> > non-coding member. Comments please?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


RE: [PROPOSAL] Committer access and responsibilities...

Posted by Danny Angus <da...@apache.org>.
+0

I like this, I think it is needed, as it should help to extend the
experience and knowledge of the community by acknowledging the services of
non-coders.

I believe, though, that as sub-projects grow we will eventually need to
address the issue of scope, but in the meantime this would be an
improvement.

But Pier, it doesn't address your original problem though, does it?
Which was about the "bar height", or how to encourage contributors, and
increase the number of contributors without diluting, and clogging up, the
community and decision making processes.

d.

> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and
> overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
>
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?













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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
> 
> -- jt (who is afraid Pier will do a mailing list search on him and
> realize how little value he brings to the community =)

+1 on humor ;) 
You can add some extra by committing my patches for turbine-2.. ))


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 11:38, James Taylor wrote:
> 
> > My projects haven't come to a grinding halt.  Only on general @ jakarta
> 
> But this isn't about your projects, it is about the community, and the
> community is more important than the code. Do you even know why you are
> here?
> 

No.. how about you enlighten me?

> > -Andy
> 
> -- jt (who is afraid Pier will do a mailing list search on him and
> realize how little value he brings to the community =)
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
> Hints for newbies, make your CVS commits small, so your overall activity
> meter will grow. Two lines at a time, and if you have a nice file of 1000
> lines, you get 500 points just for that...
> 

I'll try and remember that next time.  

Can    //;
  //;
   We //;
  //;  
  //;
get //;
  //;
  //;
  //;
a  //;
  //;
  //;
line  //;
  //;
count  //;
  //;
  //;
please?  //;

> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
LOL ;-)

On Sat, 2002-05-25 at 12:43, Martin van den Bemt wrote:
> Maven provides that functionality ;))
> see http://jakarta.apache.org/turbine/maven/activity-log.html
> 
> Mvgr,
> Martin
> 
> On Sat, 2002-05-25 at 18:28, Pier Fumagalli wrote:
> > "James Taylor" <jt...@4lane.com> wrote:
> > 
> > > -- jt (who is afraid Pier will do a mailing list search on him and
> > > realize how little value he brings to the community =)
> > 
> > Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :)
> > 
> > <sarcasm>
> > 
> > Just need to grep the right files... You are a good committer, I see that
> > you have 2342 commits into the turbine CVS. Good.
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
Maven provides that functionality ;))
see http://jakarta.apache.org/turbine/maven/activity-log.html

Mvgr,
Martin

On Sat, 2002-05-25 at 18:28, Pier Fumagalli wrote:
> "James Taylor" <jt...@4lane.com> wrote:
> 
> > -- jt (who is afraid Pier will do a mailing list search on him and
> > realize how little value he brings to the community =)
> 
> Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :)
> 
> <sarcasm>
> 
> Just need to grep the right files... You are a good committer, I see that
> you have 2342 commits into the turbine CVS. Good.



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Pier Fumagalli" <pi...@betaversion.org>

> "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> > It does have the right to vote, but it's not binding (at least this is
what
> > Stefano told me two weeks ago).
> >
> > I don't want developers that are not committers to vote: a vote is
important
> > for the future of the project, and the future of Apache.
> >
> > Should we give votes to developers that are not interested in the future
of
> > Apache?
>
> Nope, we shouldn't but we should give it to those who ARE interested in
the
> future of Jakarta, or XML, and _do_stuff_ for those project, but are not
> "bound" to a particular codebase.

In cocoon, we have a documentation team now.
Documentation is in CVS.

IMO all should be in CVS, which is the project store, or the mailing lists.

> We should change our "meter" from being
> you contribute CODE to the project, to you contribure WORK to the project.

You contribute work? Ok, then you become a committer, that gets the *right*
to use the CVS, not the *need*.
If we trust him, why not give him CVS commit access?

I don't understand what rights you want to give to these "developers but not
committers".

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> Nope, we shouldn't but we should give it to those who ARE interested in the
> future of Jakarta, or XML, and _do_stuff_ for those project, but are not
> "bound" to a particular codebase. We should change our "meter" from being
> you contribute CODE to the project, to you contribure WORK to the project.

AFAIK each project can decide and vote to give rights to anyone they
feel deserve it and puts work in the project.

There is no requirement that the work is Java or C - I think there are 
people who focus more on documentation and became commiters for that. It's 
up to each project to decide by the normal rules. 

If you want to propose a lawyer to become commiter on tomcat - I'll be 
more than +1 ( we need one to solve the mystery of the JMX and 
other licences, and that would be an important contribution and worth
of making him commiter ).

I don't think that having CVS access ( without knowing what CVS is )
will be a problem for him. And if he cares or not to vote - again
I don't care.

Costin


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Nicola Ken Barozzi" <ni...@apache.org> wrote:

> It does have the right to vote, but it's not binding (at least this is what
> Stefano told me two weeks ago).
> 
> I don't want developers that are not committers to vote: a vote is important
> for the future of the project, and the future of Apache.
> 
> Should we give votes to developers that are not interested in the future of
> Apache?

Nope, we shouldn't but we should give it to those who ARE interested in the
future of Jakarta, or XML, and _do_stuff_ for those project, but are not
"bound" to a particular codebase. We should change our "meter" from being
you contribute CODE to the project, to you contribure WORK to the project.

That's at least what I (and others) think should happen. I'll try to put
together a more "formal" proposal in the next few hours/days (now it's cats
time, food and entertainment is required by my two furry creeps)...

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Pier Fumagalli" <pi...@betaversion.org>

> "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> > What is the way that *any* community decides in voting?
> >
> > You *are* a member of the community even if you do not have an account.
> >
> > http://xml.apache.org/roles.html   :
> > "
> > Developers
> >
> > Developers are the people who write code or documentation patches or
> > contribute positively to the project in other ways. A developer's
> > contribution is always recognized. In source code, all developers who
> > contribute to a source file may add their name to the list of authors
for
> > that file.
> > "
> >
> > A developer *is* part of the community.
> >
> > This is how it works on the Cocoon, Forrest and POI projects AFAIK.
> >
> > It seems that you are trying to put on paper that developers that are
not
> > committers have to be listed.
> >
> > It can be done, but why?
>
> Nicola, you might as well ask Stefano who wrote that page... I want to
point
> out one little paragraph below the one you mentioned:
>
> "A Committer has write access to the source code repository and gains
voting
> rights allowing them to affect the future of the subproject."
>
> A developer, at the end of the day, doesn't have the right to vote. When
it
> comes to numbers, he is worth less than zero... I'm sorry, but this is how
> OUR reality is right now, because we didn't think about it in the first
> place when this project (or XML) were founded (and you can trust me
because
> I was there, both times)...

It does have the right to vote, but it's not binding (at least this is what
Stefano told me two weeks ago).

I don't want developers that are not committers to vote: a vote is important
for the future of the project, and the future of Apache.

Should we give votes to developers that are not interested in the future of
Apache?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Nicola Ken Barozzi" <ni...@apache.org> wrote:

> What is the way that *any* community decides in voting?
> 
> You *are* a member of the community even if you do not have an account.
> 
> http://xml.apache.org/roles.html   :
> "
> Developers
> 
> Developers are the people who write code or documentation patches or
> contribute positively to the project in other ways. A developer's
> contribution is always recognized. In source code, all developers who
> contribute to a source file may add their name to the list of authors for
> that file.
> "
> 
> A developer *is* part of the community.
> 
> This is how it works on the Cocoon, Forrest and POI projects AFAIK.
> 
> It seems that you are trying to put on paper that developers that are not
> committers have to be listed.
> 
> It can be done, but why?

Nicola, you might as well ask Stefano who wrote that page... I want to point
out one little paragraph below the one you mentioned:

"A Committer has write access to the source code repository and gains voting
rights allowing them to affect the future of the subproject."

A developer, at the end of the day, doesn't have the right to vote. When it
comes to numbers, he is worth less than zero... I'm sorry, but this is how
OUR reality is right now, because we didn't think about it in the first
place when this project (or XML) were founded (and you can trust me because
I was there, both times)...

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Pier Fumagalli" <pi...@betaversion.org>

> "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> > If commit numbers are not so important (and I agree), then why measure
them
> > at all?
>
> If commit numbers are not so important (and I agree), what is the way that
> this community has to decide whether a person is a committer or not, given
> that as it is today, you're not recognized as a member of this community
if
> you don't have a CVS account, and your name is not listed in
$CVSROOT/avail

What is the way that *any* community decides in voting?

You *are* a member of the community even if you do not have an account.

http://xml.apache.org/roles.html   :
"
Developers

 Developers are the people who write code or documentation patches or
contribute positively to the project in other ways. A developer's
contribution is always recognized. In source code, all developers who
contribute to a source file may add their name to the list of authors for
that file.
"

A developer *is* part of the community.

This is how it works on the Cocoon, Forrest and POI projects AFAIK.

It seems that you are trying to put on paper that developers that are not
committers have to be listed.

It can be done, but why?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Nicola Ken Barozzi" <ni...@apache.org> wrote:

> If commit numbers are not so important (and I agree), then why measure them
> at all?

If commit numbers are not so important (and I agree), what is the way that
this community has to decide whether a person is a committer or not, given
that as it is today, you're not recognized as a member of this community if
you don't have a CVS account, and your name is not listed in $CVSROOT/avail

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sat, 25 May 2002, Nicola Ken Barozzi wrote:

> > I respect Craig mostly for the quality of his code ( even if I prefer
> > different solutions and we disagree on many other things ), I respect
> > Sam the most for keeping a low-key as 'PMC president' ( I never saw
> > him use the 'I'm the PMC chair' as an argument ).
> >
> > A smart idea ( like the try/catch unrolling ) is as important as
> > 100s of commits fixing bugs or 100s of mails answering questions.
> 
> If commit numbers are not so important (and I agree), then why measure them
> at all?
> 
> BTW, this is not what you said some days ago:
> http://marc.theaimsgroup.com/?l=jakarta-general&m=102112907923436&w=2

I believe my message is:
http://marc.theaimsgroup.com/?l=jakarta-general&m=102130834717179&w=2

And I said exactly the same thing, that small commits are easier to 
review and putting a 'ranking' on a commiter ( by any criteria )
is bad ( not only number of commits - also age, how long he is commiter,
how many flame-wars he participates in or how many bugs he fixes, or 
anything else ). What it matter is that he moves the project forward
and contributes his time and inteligence to the community.  


Costin


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: <co...@covalent.net>

> On Sat, 25 May 2002, Pier Fumagalli wrote:
>
> > Just need to grep the right files... You are a good committer, I see
that
> > you have 2342 commits into the turbine CVS. Good.
> >
> > I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so
> > lazy), but hear hear, Costin has 25871, beating Craig who is just at
22712,
> > and our president (Sam) at 60869... Yes yes, he deserves to be the PMC
> > president just for that...
>
> I don't think anyone can find a mail from Craig or Sam (or me) 'bragging'
> about the number of commits or how important of contribution we make and
> how people who contribute 'less' should pay attention.
>
> I respect Craig mostly for the quality of his code ( even if I prefer
> different solutions and we disagree on many other things ), I respect
> Sam the most for keeping a low-key as 'PMC president' ( I never saw
> him use the 'I'm the PMC chair' as an argument ).
>
> A smart idea ( like the try/catch unrolling ) is as important as
> 100s of commits fixing bugs or 100s of mails answering questions.

If commit numbers are not so important (and I agree), then why measure them
at all?

BTW, this is not what you said some days ago:
http://marc.theaimsgroup.com/?l=jakarta-general&m=102112907923436&w=2

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> Just need to grep the right files... You are a good committer, I see that
> you have 2342 commits into the turbine CVS. Good.
> 
> I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so
> lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712,
> and our president (Sam) at 60869... Yes yes, he deserves to be the PMC
> president just for that...

I don't think anyone can find a mail from Craig or Sam (or me) 'bragging' 
about the number of commits or how important of contribution we make and 
how people who contribute 'less' should pay attention. 

I respect Craig mostly for the quality of his code ( even if I prefer 
different solutions and we disagree on many other things ), I respect
Sam the most for keeping a low-key as 'PMC president' ( I never saw
him use the 'I'm the PMC chair' as an argument ).

A smart idea ( like the try/catch unrolling ) is as important as 
100s of commits fixing bugs or 100s of mails answering questions.

Costin


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"James Taylor" <jt...@4lane.com> wrote:

> -- jt (who is afraid Pier will do a mailing list search on him and
> realize how little value he brings to the community =)

Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :)

<sarcasm>

Just need to grep the right files... You are a good committer, I see that
you have 2342 commits into the turbine CVS. Good.

I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so
lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712,
and our president (Sam) at 60869... Yes yes, he deserves to be the PMC
president just for that...

This is such a nice way to recognized "how much" you contributed to the
foundation, isn't it?

Hints for newbies, make your CVS commits small, so your overall activity
meter will grow. Two lines at a time, and if you have a nice file of 1000
lines, you get 500 points just for that...

</sarcasm>

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by James Taylor <jt...@4lane.com>.
> My projects haven't come to a grinding halt.  Only on general @ jakarta

But this isn't about your projects, it is about the community, and the
community is more important than the code. Do you even know why you are
here?

> -Andy

-- jt (who is afraid Pier will do a mailing list search on him and
realize how little value he brings to the community =)


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 09:13, Pier Fumagalli wrote:
> Andrew C. Oliver <ac...@apache.org> wrote:
> 
> > -1, its not broken, it worked.  I see little reason to fix it.
> 
> It is broken. We don't allow Sally Khudairi to be a member of this
> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> employment and terminate his working (9 to 5) relationship with Apache,
> without leaving him with the "dues" of a committer and make him "look bad"
> because he disappeared.
> 

My projects haven't come to a grinding halt.  Only on general @ jakarta
is the sky always falling and Apache coming to an end.  I prefer the
status quo.  Nothing you've said has convinced me that (it could be that
I don't know who those people are anyhow) there is a compelling reason
to change it.  There are other things I see as more pressing than the
need for more chiefs.

-Andy

>     Pier
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
 
> The converse: You all can vote all day long on what I'm to do, but what
> are you going to do when my dissenting vote is cast by me not actually
> doing it?  Voting has NOTHING to do with what work gets done.  Thats the
> POWER of those who do.

We are talking about this proposal am I right not about a project
proposal? So if there is a veto, you can do whatever you want, but you
are doing it for nobody. Unless you want to push the proposal in, when
the opportunity is there.

> 
> > > 
> > > I offered myself as installer of Scarab and it was accepted. 
> > 
> > Guess you are a committer on jakarta? I am not. Is that the difference?
> > This is exactly the reason why I said +1.. 
> 
> If you contribute work, you'll become a committer, its as simple as
> that.  I propose people committers because I can't keep up with their
> patches and get my own work done.  (After I make sure they will fit into
> the community and they know how to use CVS).  I would like to say I
> really value the opinions of everyone, but I don't.  I value the
> opinions of those who are going to contribute something tangible to the
> project (even if its just critique of the documentation, bug reports,
> test files, etc).  

Don't think we are discussing the same thing here.. I refered to my
offer of being a sysadmin/maillist moderator. Becoming a committer of
any project isn't involved in that. Probably because you have to be
committer to do such a thing, getting involved the community is pretty
difficult. 

> 
> If +1 = "Andy Do" then thats a big -1 from me.  If +1 = "Yes and I'll do
> or help do" then great!  To let non-coders be committers cheapens the
> meaning.  
Agreed ont hat, but I guess you missed to point Pier made.. Pier wasn't
suggesting that non-coders can be committers, just that they can be
members. 

> Its just a bunch of folks registering their opinion on what I
> should do.  Yeah, the difference between that and toilette paper is that
> toilette paper is useful.

You are all (seen this reference a couple of times now) thinking of
members that take up "jakarta" management issues and that they become
leaders.. I was just referring to people who can make life easier for
the coders. If I was jakarta's sysadmin, and someones says we want to
switch to scarab, I must be able to say -1 (when supplying good
reasons..). If you have a vote on POI, as a sysmanager I don't vote on
that. The only members that can intervene in your project (if that
member role was there that is), could be the lawyers ;) En (or
de)-cryption support in POI is something that could be appropiate on
that ;)). Hope you get the "overall" picture of what I am trying to say
here.. (please don't kill me on details..)
 
> 
> Yeah the kicker is that there are no bugs in it (or at least there
> weren't a week or two ago).  Maybe Turbine is perfect? :-D

Dude.. I was searching my ass of on that crashing thing.. I guess it is
perfect then indeed ;).

Mvgr,
Martin



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 11:38, Martin van den Bemt wrote:
> On Sat, 2002-05-25 at 17:16, Andrew C. Oliver wrote:
> > 
> > I fail to see the connection between what I said and what you stated.  
> 
> Then I fail to see your connection with my story too.. 
> I'll Give it try anyway : If no one cares or just one person cares and
> needs to vote of all to get things implemented or changed and doesn't
> get that vote, it will not get implemented, or even tried.
> I think that is normal behaviour here, so that is why I guess a lot of
> idea's never get implemented anyway, because you guys -1 it.. 
> 

The converse: You all can vote all day long on what I'm to do, but what
are you going to do when my dissenting vote is cast by me not actually
doing it?  Voting has NOTHING to do with what work gets done.  Thats the
POWER of those who do.

> > 
> > I offered myself as installer of Scarab and it was accepted. 
> 
> Guess you are a committer on jakarta? I am not. Is that the difference?
> This is exactly the reason why I said +1.. 

If you contribute work, you'll become a committer, its as simple as
that.  I propose people committers because I can't keep up with their
patches and get my own work done.  (After I make sure they will fit into
the community and they know how to use CVS).  I would like to say I
really value the opinions of everyone, but I don't.  I value the
opinions of those who are going to contribute something tangible to the
project (even if its just critique of the documentation, bug reports,
test files, etc).  

If +1 = "Andy Do" then thats a big -1 from me.  If +1 = "Yes and I'll do
or help do" then great!  To let non-coders be committers cheapens the
meaning.  Its just a bunch of folks registering their opinion on what I
should do.  Yeah, the difference between that and toilette paper is that
toilette paper is useful.

> If you don't mind me asking out of interest : which project ? (else I
> have to dig into the avail file to see where you have commit access ;))
> 

Committer to POI and Lucene.  Developer/Contributer to Cocoon.

>  I'll be
> > implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> > 2. Install Scarab on it for practice, Step 3. install here)
> 
> It's broken now indeed ;) On the turbine list they are still saying that
> I have to use that to get bugs...
> 

Yeah the kicker is that there are no bugs in it (or at least there
weren't a week or two ago).  Maybe Turbine is perfect? :-D

-Andy

> Mvgr,
> Martin
> 
> > -Andy
> > 
> > On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote:
> > > Andy,
> > > 
> > > With this attitude nothing gets ever implemented I guess.
> > > 
> > > In this case Pier can hardly say : I am going to implement this and all
> > > of you comply! So he can implement whatever he wants, as long as it it
> > > still veto'd its no use investing spare time in. 
> > > I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
> > > to no avail, although some were complaining about lack of time. This new
> > > proposal will leave this kind of involvement at least open.
> > > 
> > > Mvgr,
> > > Martin
> > > 
> > > On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> > > > On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > > > > Even though I am not a committer / member (I try to contribute code
> > > > > however), I just needed to express my opinion ;).
> > > > > 
> > > > > I am a +1 on Piers proposal. 
> > > > > 
> > > > > Especially the membership possibility for people who are not coding can
> > > > > be very constructive for this community! 
> > > > > 
> > > > > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > > > > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > > > > community is more then just programming, although it is "our" core
> > > > > business here. Others can give us a look at things we didn't have before
> > > > > and make life a little bit easier for us code monkeys (or as I call
> > > > > myself in dutch "tiep miep")
> > > > > 
> > > > 
> > > > I see lots of ideas floating around.  Just few get implemented.  
> > > > 
> > > > -Andy
> > > > 
> > > > > Just my 2 euro cents ;)
> > > > > 
> > > > > Mvgr,
> > > > > Martin
> > > > > 
> > > > > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > > > > thing. So let's keep it that way and ignore the comments about that to
> > > > > each other. If you cannot mail something independend of the past,
> > > > > besidees the current subject, don't mail it or mail it in private, or
> > > > > better be the wisest to ignore it.
> > > > > <value teacher mode on>
> > > > > I am not here to teach values or something like that (you are not
> > > > > waiting for that probably), but I am going to try anyway :
> > > > > The past is something that happened and is not now, you cannot blame
> > > > > people for what has taken place then, because it is not taking place now
> > > > > (with now I mean this Nanosecond even less). Life becomes so much easier
> > > > > if you obtain this view! No barriers to look back on, just plain free,
> > > > > non prejudiced communications. Wow we live in a great world!
> > > > > Forgive me my Martin logic, you will get used to it.. ;))
> > > > > </value teacher mode off>
> > > > > 
> > > > > 
> > > > > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > > > > Andrew C. Oliver <ac...@apache.org> wrote:
> > > > > > 
> > > > > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > > > > 
> > > > > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > > > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > > > > employment and terminate his working (9 to 5) relationship with Apache,
> > > > > > without leaving him with the "dues" of a committer and make him "look bad"
> > > > > > because he disappeared.
> > > > > > 
> > > > > >     Pier
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > > > 
> > > > -- 
> > > > http://www.superlinksoftware.com - software solutions for business
> > > > http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> > > > Java                            
> > > > http://krysalis.sourceforge.net/centipede - the best build/project
> > > > structure
> > > > 		    a guy/gal could have! - Make Ant simple on complex Projects!
> > > > The avalanche has already started. It is too late for the pebbles to
> > > > vote.
> > > > -Ambassador Kosh
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > 
> > -- 
> > http://www.superlinksoftware.com - software solutions for business
> > http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> > Java                            
> > http://krysalis.sourceforge.net/centipede - the best build/project
> > structure
> > 		    a guy/gal could have! - Make Ant simple on complex Projects!
> > The avalanche has already started. It is too late for the pebbles to
> > vote.
> > -Ambassador Kosh
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
On Sat, 2002-05-25 at 17:16, Andrew C. Oliver wrote:
> 
> I fail to see the connection between what I said and what you stated.  

Then I fail to see your connection with my story too.. 
I'll Give it try anyway : If no one cares or just one person cares and
needs to vote of all to get things implemented or changed and doesn't
get that vote, it will not get implemented, or even tried.
I think that is normal behaviour here, so that is why I guess a lot of
idea's never get implemented anyway, because you guys -1 it.. 

> 
> I offered myself as installer of Scarab and it was accepted. 

Guess you are a committer on jakarta? I am not. Is that the difference?
This is exactly the reason why I said +1.. 
If you don't mind me asking out of interest : which project ? (else I
have to dig into the avail file to see where you have commit access ;))

 I'll be
> implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> 2. Install Scarab on it for practice, Step 3. install here)

It's broken now indeed ;) On the turbine list they are still saying that
I have to use that to get bugs...

Mvgr,
Martin

> -Andy
> 
> On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote:
> > Andy,
> > 
> > With this attitude nothing gets ever implemented I guess.
> > 
> > In this case Pier can hardly say : I am going to implement this and all
> > of you comply! So he can implement whatever he wants, as long as it it
> > still veto'd its no use investing spare time in. 
> > I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
> > to no avail, although some were complaining about lack of time. This new
> > proposal will leave this kind of involvement at least open.
> > 
> > Mvgr,
> > Martin
> > 
> > On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> > > On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > > > Even though I am not a committer / member (I try to contribute code
> > > > however), I just needed to express my opinion ;).
> > > > 
> > > > I am a +1 on Piers proposal. 
> > > > 
> > > > Especially the membership possibility for people who are not coding can
> > > > be very constructive for this community! 
> > > > 
> > > > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > > > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > > > community is more then just programming, although it is "our" core
> > > > business here. Others can give us a look at things we didn't have before
> > > > and make life a little bit easier for us code monkeys (or as I call
> > > > myself in dutch "tiep miep")
> > > > 
> > > 
> > > I see lots of ideas floating around.  Just few get implemented.  
> > > 
> > > -Andy
> > > 
> > > > Just my 2 euro cents ;)
> > > > 
> > > > Mvgr,
> > > > Martin
> > > > 
> > > > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > > > thing. So let's keep it that way and ignore the comments about that to
> > > > each other. If you cannot mail something independend of the past,
> > > > besidees the current subject, don't mail it or mail it in private, or
> > > > better be the wisest to ignore it.
> > > > <value teacher mode on>
> > > > I am not here to teach values or something like that (you are not
> > > > waiting for that probably), but I am going to try anyway :
> > > > The past is something that happened and is not now, you cannot blame
> > > > people for what has taken place then, because it is not taking place now
> > > > (with now I mean this Nanosecond even less). Life becomes so much easier
> > > > if you obtain this view! No barriers to look back on, just plain free,
> > > > non prejudiced communications. Wow we live in a great world!
> > > > Forgive me my Martin logic, you will get used to it.. ;))
> > > > </value teacher mode off>
> > > > 
> > > > 
> > > > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > > > Andrew C. Oliver <ac...@apache.org> wrote:
> > > > > 
> > > > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > > > 
> > > > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > > > employment and terminate his working (9 to 5) relationship with Apache,
> > > > > without leaving him with the "dues" of a committer and make him "look bad"
> > > > > because he disappeared.
> > > > > 
> > > > >     Pier
> > > > > 
> > > > > 
> > > > > --
> > > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > > 
> > > -- 
> > > http://www.superlinksoftware.com - software solutions for business
> > > http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> > > Java                            
> > > http://krysalis.sourceforge.net/centipede - the best build/project
> > > structure
> > > 		    a guy/gal could have! - Make Ant simple on complex Projects!
> > > The avalanche has already started. It is too late for the pebbles to
> > > vote.
> > > -Ambassador Kosh
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > 
> > > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> -- 
> http://www.superlinksoftware.com - software solutions for business
> http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> Java                            
> http://krysalis.sourceforge.net/centipede - the best build/project
> structure
> 		    a guy/gal could have! - Make Ant simple on complex Projects!
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 11:38, Pier Fumagalli wrote:
> "Andrew C. Oliver" <ac...@apache.org> wrote:
> 
> > 
> > I fail to see the connection between what I said and what you stated.
> > 
> > I offered myself as installer of Scarab and it was accepted.  I'll be
> > implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> > 2. Install Scarab on it for practice, Step 3. install here)
> 
> Good. If you weren't a committer for POI, and you did that for the past 2
> years, wouldn't you like to have a some sort of recognition by this
> community? Wouldn't you like to be able to elect the PMC? To decide what
> projects you'll have to deal with in your installation of the bug tracking
> system? I believe you would.
> 

And that is why I think there should be an infrastructure project.  The
infrastructure project would give credibility to such persons and remove
it from general @.  But if we're going to give lawyers and nannies
voting rights in POI...well thats not real high on my list of good
things.

-Andy

>     Pier
> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Andrew C. Oliver" <ac...@apache.org> wrote:

> 
> I fail to see the connection between what I said and what you stated.
> 
> I offered myself as installer of Scarab and it was accepted.  I'll be
> implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> 2. Install Scarab on it for practice, Step 3. install here)

Good. If you weren't a committer for POI, and you did that for the past 2
years, wouldn't you like to have a some sort of recognition by this
community? Wouldn't you like to be able to elect the PMC? To decide what
projects you'll have to deal with in your installation of the bug tracking
system? I believe you would.

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
I fail to see the connection between what I said and what you stated.  

I offered myself as installer of Scarab and it was accepted.  I'll be
implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
2. Install Scarab on it for practice, Step 3. install here)

-Andy

On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote:
> Andy,
> 
> With this attitude nothing gets ever implemented I guess.
> 
> In this case Pier can hardly say : I am going to implement this and all
> of you comply! So he can implement whatever he wants, as long as it it
> still veto'd its no use investing spare time in. 
> I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
> to no avail, although some were complaining about lack of time. This new
> proposal will leave this kind of involvement at least open.
> 
> Mvgr,
> Martin
> 
> On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> > On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > > Even though I am not a committer / member (I try to contribute code
> > > however), I just needed to express my opinion ;).
> > > 
> > > I am a +1 on Piers proposal. 
> > > 
> > > Especially the membership possibility for people who are not coding can
> > > be very constructive for this community! 
> > > 
> > > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > > community is more then just programming, although it is "our" core
> > > business here. Others can give us a look at things we didn't have before
> > > and make life a little bit easier for us code monkeys (or as I call
> > > myself in dutch "tiep miep")
> > > 
> > 
> > I see lots of ideas floating around.  Just few get implemented.  
> > 
> > -Andy
> > 
> > > Just my 2 euro cents ;)
> > > 
> > > Mvgr,
> > > Martin
> > > 
> > > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > > thing. So let's keep it that way and ignore the comments about that to
> > > each other. If you cannot mail something independend of the past,
> > > besidees the current subject, don't mail it or mail it in private, or
> > > better be the wisest to ignore it.
> > > <value teacher mode on>
> > > I am not here to teach values or something like that (you are not
> > > waiting for that probably), but I am going to try anyway :
> > > The past is something that happened and is not now, you cannot blame
> > > people for what has taken place then, because it is not taking place now
> > > (with now I mean this Nanosecond even less). Life becomes so much easier
> > > if you obtain this view! No barriers to look back on, just plain free,
> > > non prejudiced communications. Wow we live in a great world!
> > > Forgive me my Martin logic, you will get used to it.. ;))
> > > </value teacher mode off>
> > > 
> > > 
> > > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > > Andrew C. Oliver <ac...@apache.org> wrote:
> > > > 
> > > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > > 
> > > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > > employment and terminate his working (9 to 5) relationship with Apache,
> > > > without leaving him with the "dues" of a committer and make him "look bad"
> > > > because he disappeared.
> > > > 
> > > >     Pier
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > 
> > -- 
> > http://www.superlinksoftware.com - software solutions for business
> > http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> > Java                            
> > http://krysalis.sourceforge.net/centipede - the best build/project
> > structure
> > 		    a guy/gal could have! - Make Ant simple on complex Projects!
> > The avalanche has already started. It is too late for the pebbles to
> > vote.
> > -Ambassador Kosh
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
Andy,

With this attitude nothing gets ever implemented I guess.

In this case Pier can hardly say : I am going to implement this and all
of you comply! So he can implement whatever he wants, as long as it it
still veto'd its no use investing spare time in. 
I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
to no avail, although some were complaining about lack of time. This new
proposal will leave this kind of involvement at least open.

Mvgr,
Martin

On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > Even though I am not a committer / member (I try to contribute code
> > however), I just needed to express my opinion ;).
> > 
> > I am a +1 on Piers proposal. 
> > 
> > Especially the membership possibility for people who are not coding can
> > be very constructive for this community! 
> > 
> > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > community is more then just programming, although it is "our" core
> > business here. Others can give us a look at things we didn't have before
> > and make life a little bit easier for us code monkeys (or as I call
> > myself in dutch "tiep miep")
> > 
> 
> I see lots of ideas floating around.  Just few get implemented.  
> 
> -Andy
> 
> > Just my 2 euro cents ;)
> > 
> > Mvgr,
> > Martin
> > 
> > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > thing. So let's keep it that way and ignore the comments about that to
> > each other. If you cannot mail something independend of the past,
> > besidees the current subject, don't mail it or mail it in private, or
> > better be the wisest to ignore it.
> > <value teacher mode on>
> > I am not here to teach values or something like that (you are not
> > waiting for that probably), but I am going to try anyway :
> > The past is something that happened and is not now, you cannot blame
> > people for what has taken place then, because it is not taking place now
> > (with now I mean this Nanosecond even less). Life becomes so much easier
> > if you obtain this view! No barriers to look back on, just plain free,
> > non prejudiced communications. Wow we live in a great world!
> > Forgive me my Martin logic, you will get used to it.. ;))
> > </value teacher mode off>
> > 
> > 
> > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > Andrew C. Oliver <ac...@apache.org> wrote:
> > > 
> > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > 
> > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > employment and terminate his working (9 to 5) relationship with Apache,
> > > without leaving him with the "dues" of a committer and make him "look bad"
> > > because he disappeared.
> > > 
> > >     Pier
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > > 
> > > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> -- 
> http://www.superlinksoftware.com - software solutions for business
> http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> Java                            
> http://krysalis.sourceforge.net/centipede - the best build/project
> structure
> 		    a guy/gal could have! - Make Ant simple on complex Projects!
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> Even though I am not a committer / member (I try to contribute code
> however), I just needed to express my opinion ;).
> 
> I am a +1 on Piers proposal. 
> 
> Especially the membership possibility for people who are not coding can
> be very constructive for this community! 
> 
> Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> community is more then just programming, although it is "our" core
> business here. Others can give us a look at things we didn't have before
> and make life a little bit easier for us code monkeys (or as I call
> myself in dutch "tiep miep")
> 

I see lots of ideas floating around.  Just few get implemented.  

-Andy

> Just my 2 euro cents ;)
> 
> Mvgr,
> Martin
> 
> PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> thing. So let's keep it that way and ignore the comments about that to
> each other. If you cannot mail something independend of the past,
> besidees the current subject, don't mail it or mail it in private, or
> better be the wisest to ignore it.
> <value teacher mode on>
> I am not here to teach values or something like that (you are not
> waiting for that probably), but I am going to try anyway :
> The past is something that happened and is not now, you cannot blame
> people for what has taken place then, because it is not taking place now
> (with now I mean this Nanosecond even less). Life becomes so much easier
> if you obtain this view! No barriers to look back on, just plain free,
> non prejudiced communications. Wow we live in a great world!
> Forgive me my Martin logic, you will get used to it.. ;))
> </value teacher mode off>
> 
> 
> On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > Andrew C. Oliver <ac...@apache.org> wrote:
> > 
> > > -1, its not broken, it worked.  I see little reason to fix it.
> > 
> > It is broken. We don't allow Sally Khudairi to be a member of this
> > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > employment and terminate his working (9 to 5) relationship with Apache,
> > without leaving him with the "dues" of a committer and make him "look bad"
> > because he disappeared.
> > 
> >     Pier
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Martin van den Bemt" <ml...@mvdb.net> wrote:

> Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> community is more then just programming, although it is "our" core
> business here. Others can give us a look at things we didn't have before
> and make life a little bit easier for us code monkeys (or as I call
> myself in dutch "tiep miep")

_THIS_ is freedom. It doesn't look like a "vicious abuse"... Thank you
Martin...

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
Even though I am not a committer / member (I try to contribute code
however), I just needed to express my opinion ;).

I am a +1 on Piers proposal. 

Especially the membership possibility for people who are not coding can
be very constructive for this community! 

Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
sys admins, people with great ideas ("the thinkers")  etc,etc.. A
community is more then just programming, although it is "our" core
business here. Others can give us a look at things we didn't have before
and make life a little bit easier for us code monkeys (or as I call
myself in dutch "tiep miep")

Just my 2 euro cents ;)

Mvgr,
Martin

PS this is not a pro Pier (or whoever) and con Costin (or whoever)
thing. So let's keep it that way and ignore the comments about that to
each other. If you cannot mail something independend of the past,
besidees the current subject, don't mail it or mail it in private, or
better be the wisest to ignore it.
<value teacher mode on>
I am not here to teach values or something like that (you are not
waiting for that probably), but I am going to try anyway :
The past is something that happened and is not now, you cannot blame
people for what has taken place then, because it is not taking place now
(with now I mean this Nanosecond even less). Life becomes so much easier
if you obtain this view! No barriers to look back on, just plain free,
non prejudiced communications. Wow we live in a great world!
Forgive me my Martin logic, you will get used to it.. ;))
</value teacher mode off>


On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> Andrew C. Oliver <ac...@apache.org> wrote:
> 
> > -1, its not broken, it worked.  I see little reason to fix it.
> 
> It is broken. We don't allow Sally Khudairi to be a member of this
> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> employment and terminate his working (9 to 5) relationship with Apache,
> without leaving him with the "dues" of a committer and make him "look bad"
> because he disappeared.
> 
>     Pier
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
> 
> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good democratic country. Are
> we undermining that?

Hmm.. democracy is also having the right not to vote. Just don't
complain if you don't like what happened after the vote..

Mvgr,
Martin



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good democratic country. Are
> we undermining that?
> 

you also have the right to abstain.  Sometimes you speak loudest by not
speaking at all.

>     Pier
> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Ted Husted <hu...@apache.org>.
Personally, I would say the Jakarta system is most like a judicial
system. It's not the lawmaking or executive branch that is so often
exposed to democracy, but the judicial branch, which is often held above
democracy -- and in the US is used to keep the mob in check. 

Committers don't make laws, disburse funds, or arrest felons. They
simply judge whether code or documentation is product-worthy. 

What we do now is not democratic -- it's pragmatic. 

And so I would agree with Pier. Part of agreeing to be a Committer is
agreeing to weigh in, even if to abstain (+0). There is no provision for
removing a Committer for non-voting, but I would say that voting counts
as participating as to someone's active/inactive status. It may in fact
be a good idea for the release managers to ping any non-voting
Committers before moving forward, as has been done for PMC votes. =:0)

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Pier Fumagalli wrote:
>
> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good democratic country. Are
> we undermining that?
> 
>     Pier

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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
On Sat, 2002-05-25 at 19:03, Andrew C. Oliver wrote:
> The action worthy of merit being: Surviving adolescence?

Too many words I need a dictionary for ;)) (it's hard to discuss stuff
you have to get out of a dictionary, so I will not try that)
I will conclude this day of way too little coding by using the footer I
just seen on Nicola's mail : 

            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

Let's I made the choice to remain ;).


Mvgr,
Martin van den Bemt 


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 12:53, Martin van den Bemt wrote:
> > its a meritocracy. 
> 
> Thanx to the Oxfort dictionary I know what it is.. But all democracies
> are actually meritocracies according to the dictionary, they select you
> to be able to vote when 18+. But this is getting way to Off-Topic I
> guess... ;))
> 

The action worthy of merit being: Surviving adolescence?

> Mvgr,
> Martin
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Martin van den Bemt <ml...@mvdb.net>.
> its a meritocracy. 

Thanx to the Oxfort dictionary I know what it is.. But all democracies
are actually meritocracies according to the dictionary, they select you
to be able to vote when 18+. But this is getting way to Off-Topic I
guess... ;))

Mvgr,
Martin



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
> No, it isn't.
> In a true democracy, one has the right to abstain.
> 
> IMO that a good democracy doesn't need strong feelings: many dictators go to
> power with a strong vote with a strong turnout, while one of the major
> democracies of the world, the US, doen't surely have one of the highest
> turnouts.
> 

For the record, technically the US is a democratic republic and not a
"Democracy".  The low turnout in part reflects that.  We vote *against*
things not for them.  Hence our representatives try to say next to
nothing that they could get voted against on.  (this isn't unpatriotic
or a complaint, its just facts).  As a test of this, be an incumbent and
run on something that people are against, make a racist comment or
something...you'll find your opponent does really well.  

For example.  I did vote in the last presidential election, but it made
little sense to do so.  The electoral votes in North Carolina were
decided LONG before I cast my ballet.  So in a sense, when it came to
actually picking the man, my vote actually did not count.  (You vote for
your states electors, the electors vote for the president...so if your
electors vote for the other guy...well your vote meant nothing on the
scale of things...if you don't win...your issues have to wait till next
time)

>From my understanding, in most European parliamentary democracies,
generally you vote for more issue-oriented parties.  Even if you "loose"
you take a certain number of seats.  So it makes sense to vote
regardless of whether its going to be a landslide.

But as far as I know Jakarta is not a democracy...its a meritocracy. 

-Andy

> Just my 2euros.
> 
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by James Taylor <jt...@4lane.com>.
> while one of the major
> democracies of the world, the US, doen't surely have one of the highest
> turnouts.

And a lot of people see that as a really bad thing. Turning in an empty
ballot is one thing, but not going to the polls because you can't tear
yourself away from 'Must See TV' is ignoring your responsibility as a
citizen.

-- jt


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Pier Fumagalli" <pi...@betaversion.org>

> "Nicola Ken Barozzi" <ni...@apache.org> wrote:
> > From: "Pier Fumagalli" <pi...@betaversion.org>
> >
> >> Being a committer (at least that's my idea), he doesn't only have the
> >> "right" to vote, but also the "due" to vote...
> >>
> >> This is one of the fundamental concepts of any good democratic country.
> >> Are we undermining that?
> >
> > No, it isn't.
> > In a true democracy, one has the right to abstain.
>
> Correct... In every official Apache ballot (foundation crap, legal stuff),
> you always have three options:
>
> [ ] Yes
> [ ] No
> [ ] Abstain
>
> But I feel it's a due for all foundation members to at least tick one of
> those boxes (got upset with a couple of very close friends of mine because
> they didn't show up at the members meeting last week)...
>
> You can abstain, but you shouldn't "ignore"...
>
> <higher-bandwidth language="italian">
>     Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o
>     non andare a votare?
> </higher-bandwidth>

 <higher-bandwidth language="italian">
     Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o
     non andare a votare?
 </higher-bandwidth>

Dipende dal messaggio che vuoi dare...

> (Translated it would sound like: what's more "right" democratically
> speaking, going to poll booth and put in an unticked voter's card, or not
> even caring about going to vote? - But I don't know if it makes sense in
> English... Andy?)

I always thought that voters has at least a "moral" due to vote.

But I have noted that when a democtratic system is sane, the percentages of
the two major parties are similar.
This keeps a healthy tension between them, that keeps the actions of the
ruling party in control.

I have also noted that high turnouts usually mean that the voters are upset
by something, or that the vote is particularly important.
These cases usually involve a lot of tensions.

Out of these simple observations, I have cone not to disdain low turnouts,
and appreciate the fact that there are really 4 votes:

 [ ] Yes
 [ ] No
 [ ] Abstain
 [ ] whatever

Don't we have a similar system (the +-0 is even more)?

+1
-1
+-0
no vote

These votes are different in meaning:

 [ 3] Yes
 [ 1] No
 [ 10] Abstain
 [ 1] Whatever

(I want you to take a decision on this matter, but I don't know what is
best; please try to lobby the -1 or find a compromise)

 [ 3] Yes
 [ 1] No
 [1] Abstain
 [10] Whatever

(I don't care whatever happens, you could even not decide on this issue and
drop it: if there is a -1, don't mind lobbying too much, I will never back
you)

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Nicola Ken Barozzi" <ni...@apache.org> wrote:
> From: "Pier Fumagalli" <pi...@betaversion.org>
> 
>> Being a committer (at least that's my idea), he doesn't only have the
>> "right" to vote, but also the "due" to vote...
>> 
>> This is one of the fundamental concepts of any good democratic country.
>> Are we undermining that?
> 
> No, it isn't.
> In a true democracy, one has the right to abstain.

Correct... In every official Apache ballot (foundation crap, legal stuff),
you always have three options:

[ ] Yes
[ ] No
[ ] Abstain

But I feel it's a due for all foundation members to at least tick one of
those boxes (got upset with a couple of very close friends of mine because
they didn't show up at the members meeting last week)...

You can abstain, but you shouldn't "ignore"...

<higher-bandwidth language="italian">
    Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o
    non andare a votare?
</higher-bandwidth>

(Translated it would sound like: what's more "right" democratically
speaking, going to poll booth and put in an unticked voter's card, or not
even caring about going to vote? - But I don't know if it makes sense in
English... Andy?)

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Pier Fumagalli" <pi...@betaversion.org>

> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
>
> This is one of the fundamental concepts of any good democratic country.
Are
> we undermining that?

No, it isn't.
In a true democracy, one has the right to abstain.

IMO that a good democracy doesn't need strong feelings: many dictators go to
power with a strong vote with a strong turnout, while one of the major
democracies of the world, the US, doen't surely have one of the highest
turnouts.

Just my 2euros.

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:

> On Sat, 25 May 2002, Pier Fumagalli wrote:
> 
>> Andrew C. Oliver <ac...@apache.org> wrote:
>> 
>>> -1, its not broken, it worked.  I see little reason to fix it.
>> 
>> It is broken. We don't allow Sally Khudairi to be a member of this
>> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
>> employment and terminate his working (9 to 5) relationship with Apache,
>> without leaving him with the "dues" of a committer and make him "look bad"
>> because he disappeared.
> 
> What harm is James Todd doing ? Since there are 6 months from his last
> activity you can request the removal of his account - but I don't see
> why he ( or James Davidson or Anil ) should be removed for disappearing.
> If they'll never come back - that's fine and it doesn't hurts nobody.
> But their name remains listed in many source files and should remain
> in the list of commiters.
> 
> Todd is still listed in @author tags in quite a few files ( used by both
> 3.x and 4.x - in tomcat-util package ). And there is nothing wrong with
> 9-5 contributions, there are many people who have jobs related with apache
> projects. 

Being a committer (at least that's my idea), he doesn't only have the
"right" to vote, but also the "due" to vote...

This is one of the fundamental concepts of any good democratic country. Are
we undermining that?

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> Andrew C. Oliver <ac...@apache.org> wrote:
> 
> > -1, its not broken, it worked.  I see little reason to fix it.
> 
> It is broken. We don't allow Sally Khudairi to be a member of this
> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> employment and terminate his working (9 to 5) relationship with Apache,
> without leaving him with the "dues" of a committer and make him "look bad"
> because he disappeared.

What harm is James Todd doing ? Since there are 6 months from his last 
activity you can request the removal of his account - but I don't see 
why he ( or James Davidson or Anil ) should be removed for disappearing.
If they'll never come back - that's fine and it doesn't hurts nobody.
But their name remains listed in many source files and should remain 
in the list of commiters.

Todd is still listed in @author tags in quite a few files ( used by both
3.x and 4.x - in tomcat-util package ). And there is nothing wrong with 
9-5 contributions, there are many people who have jobs related with apache
projects. 


Costin





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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
Andrew C. Oliver <ac...@apache.org> wrote:

> -1, its not broken, it worked.  I see little reason to fix it.

It is broken. We don't allow Sally Khudairi to be a member of this
community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
employment and terminate his working (9 to 5) relationship with Apache,
without leaving him with the "dues" of a committer and make him "look bad"
because he disappeared.

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by "Andrew C. Oliver" <ac...@apache.org>.
-1, its not broken, it worked.  I see little reason to fix it.

On Fri, 2002-05-24 at 21:11, Henri Yandell wrote:
> 
> +1.
> 
> Another example if I could. The job role of 'Java admin' is growing more
> and more at companies. Developers shouldn't be adminning things, but would
> you have your unix or oracle admin be the admin of the Java side with zero
> Java knowledge?
> 
> Jakarta houses the 'Java' community at Apache but there's no way for a
> Java admin to be a part of that community. Helping other admins, writing
> documentation, being a consumer at the coders. The only way it can happen
> is if they become a coder, and that's contrary to the concept of a Java
> admin.
> 
> I think Pier's suggestion will help to grow the 'ownership' of the
> projects and the apache way of thinking to a larger audience.
> 
> Some possible negatives:
> 
> With more non-codery people around, will the 'noise' level in mail lists
> be too high for coders to want to pay attention?
> [It already is getting that way I find. I delete entire threads if the
> first couple of mails are not of interest to me. It has to be retitled as
> with this email to make me realise there was more going on than the
> original mails. ]
> 
> By growing a large community of non-coders, the coders could have less say
> in the product. Is this good/bad? How would the +1/-1 system work. Would
> votes be open to committers only in some instances, and to non-committing
> members only in others. Who votes membership vs committership vs
> contributorship?
> 
> 
> None of them that hard to answer I imagine.
> 
> Hen
> 
> On Sat, 25 May 2002, Pier Fumagalli wrote:
> 
> > Chatted with a lot of people, seen many, different development models, went
> > around, asked, talked, and I believe I have a pretty decent picture, and
> > maybe even a solution...
> >
> > So, given this little background, I would like to ask to the PMC, and all
> > other committers, if others agree that we should "splitting" the "committer"
> > figure in two parts:
> >
> > - contributor: a contributor is someone who has access to a particular CVS
> > tree, but for any reason doesn't want/need to be involved with the whole
> > Jakarta community. He just wants to code his little bit and live a long
> > life.
> >
> > - member: is someone who is involved with the Jakarta community, somehow,
> > somewhere (might be just giving a great deal in supporting users of our
> > projects, or providing extra value to projects, like guidance in respect to
> > overall specifications, binary builds). He is effectively a member of the
> > community and has all the rights and dues of every member, such as
> > participate in the election of the PMC.
> >
> > And redefining the figure of the "committer" as follows:
> >
> > - committer: is a contributor, but also a member, therefore he has all the
> > privileges and dues of a contributor (having CVS access, and overlooking the
> > code he's contributing to) and of a member (can vote for PMCs, should
> > participate and contribute to discussions on the overall structure of
> > Jakarta).
> >
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
Henri Yandell <ba...@generationjava.com> wrote:
> 
> +1.
> 
> Another example if I could. The job role of 'Java admin' is growing more
> and more at companies. Developers shouldn't be adminning things, but would
> you have your unix or oracle admin be the admin of the Java side with zero
> Java knowledge?
> 
> Jakarta houses the 'Java' community at Apache but there's no way for a
> Java admin to be a part of that community. Helping other admins, writing
> documentation, being a consumer at the coders. The only way it can happen
> is if they become a coder, and that's contrary to the concept of a Java
> admin.

That's where my career is going to lately, I didn't think about that in the
first place. I'm going to loose my "committer" status soon now that you make
me think about it! :) :) :)

> I think Pier's suggestion will help to grow the 'ownership' of the
> projects and the apache way of thinking to a larger audience.

Thanks...

> Some possible negatives:
> 
> With more non-codery people around, will the 'noise' level in mail lists
> be too high for coders to want to pay attention?
> [It already is getting that way I find. I delete entire threads if the
> first couple of mails are not of interest to me. It has to be retitled as
> with this email to make me realise there was more going on than the
> original mails. ]

That might as well happen, although I don't feel that there will be many in
one of the two categories without being a "committer". Probably a some more
in the "contributor" side of things (because of corporate involvement and
stuff), but not the other way around... But I believe that we shouldn't give
up this option...

> By growing a large community of non-coders, the coders could have less say
> in the product. Is this good/bad? How would the +1/-1 system work. Would
> votes be open to committers only in some instances, and to non-committing
> members only in others. Who votes membership vs committership vs
> contributorship?

Regarding votes, I believe that the votes for a particular codebase should
be open only to contributors only of that particular codebase, and that's it
(I'm not going to vote on Ant for example, or Turbine)... Votes regarding
accepting new codebases, starting new subprojects,  electing the PMC, that
should go only to members, not contributors...

My stance would be that if you start off being a contributor, no question
asked (from that point of view)... Patch contribute, do all you want and
need, you have fun? You want to spend more time on it and Jakarta is not
only something you're paid to work on? Kewl, just ask, could be fairly
automatic, it might as well happen automatically if someone "nominates" you
to do that... I don't think that a vote is even necessary to promote a
committer who wants to be a contributor, talk with someone who can sponsor
you, and I'll be fine...

For the ones who want to start as member, the procedure to become a
committer on one particular projects are already there, as if I wanted to
start giving some patches to (for example) Ant, and get involved with that
codebase...

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
Henri Yandell <ba...@generationjava.com> wrote:
> 
> +1.
> 
> Another example if I could. The job role of 'Java admin' is growing more
> and more at companies. Developers shouldn't be adminning things, but would
> you have your unix or oracle admin be the admin of the Java side with zero
> Java knowledge?
> 
> Jakarta houses the 'Java' community at Apache but there's no way for a
> Java admin to be a part of that community. Helping other admins, writing
> documentation, being a consumer at the coders. The only way it can happen
> is if they become a coder, and that's contrary to the concept of a Java
> admin.

That's where my career is going to lately, I didn't think about that in the
first place. I'm going to loose my "committer" status soon now that you make
me think about it! :) :) :)

> I think Pier's suggestion will help to grow the 'ownership' of the
> projects and the apache way of thinking to a larger audience.

Thanks...

> Some possible negatives:
> 
> With more non-codery people around, will the 'noise' level in mail lists
> be too high for coders to want to pay attention?
> [It already is getting that way I find. I delete entire threads if the
> first couple of mails are not of interest to me. It has to be retitled as
> with this email to make me realise there was more going on than the
> original mails. ]

That might as well happen, although I don't feel that there will be many in
one of the two categories without being a "committer". Probably a some more
in the "contributor" side of things (because of corporate involvement and
stuff), but not the other way around... But I believe that we shouldn't give
up this option...

> By growing a large community of non-coders, the coders could have less say
> in the product. Is this good/bad? How would the +1/-1 system work. Would
> votes be open to committers only in some instances, and to non-committing
> members only in others. Who votes membership vs committership vs
> contributorship?

Regarding votes, I believe that the votes for a particular codebase should
be open only to contributors only of that particular codebase, and that's it
(I'm not going to vote on Ant for example, or Turbine)... Votes regarding
accepting new codebases, starting new subprojects,  electing the PMC, that
should go only to members, not contributors...

My stance would be that if you start off being a contributor, no question
asked (from that point of view)... Patch contribute, do all you want and
need, you have fun? You want to spend more time on it and Jakarta is not
only something you're paid to work on? Kewl, just ask, could be fairly
automatic, it might as well happen automatically if someone "nominates" you
to do that... I don't think that a vote is even necessary to promote a
committer who wants to be a contributor, talk with someone who can sponsor
you, and I'll be fine...

For the ones who want to start as member, the procedure to become a
committer on one particular projects are already there, as if I wanted to
start giving some patches to (for example) Ant, and get involved with that
codebase...

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Henri Yandell <ba...@generationjava.com>.
+1.

Another example if I could. The job role of 'Java admin' is growing more
and more at companies. Developers shouldn't be adminning things, but would
you have your unix or oracle admin be the admin of the Java side with zero
Java knowledge?

Jakarta houses the 'Java' community at Apache but there's no way for a
Java admin to be a part of that community. Helping other admins, writing
documentation, being a consumer at the coders. The only way it can happen
is if they become a coder, and that's contrary to the concept of a Java
admin.

I think Pier's suggestion will help to grow the 'ownership' of the
projects and the apache way of thinking to a larger audience.

Some possible negatives:

With more non-codery people around, will the 'noise' level in mail lists
be too high for coders to want to pay attention?
[It already is getting that way I find. I delete entire threads if the
first couple of mails are not of interest to me. It has to be retitled as
with this email to make me realise there was more going on than the
original mails. ]

By growing a large community of non-coders, the coders could have less say
in the product. Is this good/bad? How would the +1/-1 system work. Would
votes be open to committers only in some instances, and to non-committing
members only in others. Who votes membership vs committership vs
contributorship?


None of them that hard to answer I imagine.

Hen

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
>
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
>
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
>
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
>
> And redefining the figure of the "committer" as follows:
>
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
>


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


Re: subverting CVS WAS: Re: Divorcing karma from CVS access? (Re:Vicious Abuse?)

Posted by "Andrew C. Oliver" <ac...@apache.org>.
> 
> As for now, I'd be happy when I see Scarab b7+ running <nudge nudge>
> 

Status on that is this:

1. Monday is a holiday
2. Sometime next week I hope/plan to drive my server back to its
"co-located home" 

3. Test detonate my Scarab installing on it (appreciate here that I'm
taking more care not to screw up Apache servers than I do my own ;-) )

> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Re: subverting CVS WAS: Re: Divorcing karma from CVS access? (Re:Vicious Abuse?)

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Andrew C. Oliver" <ac...@apache.org>

> So is there an interest in one day migrating to subversion?  I don't
> think its *ready* yet but I've always wanted to try it.  I never have,
> because I thought "well I'd like to try a lot of things but as long as I
> won't be able to use it most places whats the point".  A tentative yes
> here might give me motivation.

I think that everyone here would like a better thing than CVS, and
Subversion is maybe the biggest hope.

What I would like to know, since there are coders here that use it, what is
the "real" status and what can we expect the reasonable adoption in Apache
to be.

As for now, I'd be happy when I see Scarab b7+ running <nudge nudge>

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


subverting CVS WAS: Re: Divorcing karma from CVS access? (Re: Vicious Abuse?)

Posted by "Andrew C. Oliver" <ac...@apache.org>.
So is there an interest in one day migrating to subversion?  I don't
think its *ready* yet but I've always wanted to try it.  I never have,
because I thought "well I'd like to try a lot of things but as long as I
won't be able to use it most places whats the point".  A tentative yes
here might give me motivation.

-Andy


> - (random thoughts..) The whole notion of defining a person's worth in
>   terms of their CVS access seems backwards and wrong. The
>   'committer/non-committer' dividing line is an artifact of CVS's
>   coarse-grained access control, and will disappear once we migrate to
>   Subversion or whatever. It would be nice if there was a 'rating'
>   system that didn't hijack the versioning system's terminology. Karma
>   rated on a different scale to CVS access. Then there could be a
>   one-way mapping, X karma -> Y CVS access. The karma system could be
>   something like advogato's (http://www.advogato.org/trust-metric.html
>   http://www.advogato.org/person/).
> 
> 
> --Jeff
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


Divorcing karma from CVS access? (Re: Vicious Abuse?)

Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, May 25, 2002 at 03:51:54PM +0100, Pier Fumagalli wrote:
> "Jeff Turner" <je...@socialchange.net.au> wrote:
> 
> > .. and thankful that people like Costin persevere in spite of rather
> > vicious abuse.
> 
> Vicious abuse? All I am proposing is to add greater flexibility to the
> freedom of those who are involved with the Jakarta project.

I was objecting to unprovoked Costin-bashing outside tomcat-dev, not
your proposal. People outside tomcat-dev may not understand why a PMC
member deserved your comments ;P

As for your proposal, a few thoughts:

- AFAIK there is no requirement that a committer be a coder. See the
  definition on http://jakarta.apache.org/site/roles.html. An example:
  Diana Shannon voted as a Cocoon committer, for volunteering to
  coordinate docs:
  http://marc.theaimsgroup.com/?t=101896493700004&r=1&w=2

- Your proposal redefined 'contributor' to include CVS access, and I
  think that will cause confusion with the existing, looser meaning.

- (random thoughts..) The whole notion of defining a person's worth in
  terms of their CVS access seems backwards and wrong. The
  'committer/non-committer' dividing line is an artifact of CVS's
  coarse-grained access control, and will disappear once we migrate to
  Subversion or whatever. It would be nice if there was a 'rating'
  system that didn't hijack the versioning system's terminology. Karma
  rated on a different scale to CVS access. Then there could be a
  one-way mapping, X karma -> Y CVS access. The karma system could be
  something like advogato's (http://www.advogato.org/trust-metric.html
  http://www.advogato.org/person/).


--Jeff

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


Divorcing karma from CVS access? (Re: Vicious Abuse?)

Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, May 25, 2002 at 03:51:54PM +0100, Pier Fumagalli wrote:
> "Jeff Turner" <je...@socialchange.net.au> wrote:
> 
> > .. and thankful that people like Costin persevere in spite of rather
> > vicious abuse.
> 
> Vicious abuse? All I am proposing is to add greater flexibility to the
> freedom of those who are involved with the Jakarta project.

I was objecting to unprovoked Costin-bashing outside tomcat-dev, not
your proposal. People outside tomcat-dev may not understand why a PMC
member deserved your comments ;P

As for your proposal, a few thoughts:

- AFAIK there is no requirement that a committer be a coder. See the
  definition on http://jakarta.apache.org/site/roles.html. An example:
  Diana Shannon voted as a Cocoon committer, for volunteering to
  coordinate docs:
  http://marc.theaimsgroup.com/?t=101896493700004&r=1&w=2

- Your proposal redefined 'contributor' to include CVS access, and I
  think that will cause confusion with the existing, looser meaning.

- (random thoughts..) The whole notion of defining a person's worth in
  terms of their CVS access seems backwards and wrong. The
  'committer/non-committer' dividing line is an artifact of CVS's
  coarse-grained access control, and will disappear once we migrate to
  Subversion or whatever. It would be nice if there was a 'rating'
  system that didn't hijack the versioning system's terminology. Karma
  rated on a different scale to CVS access. Then there could be a
  one-way mapping, X karma -> Y CVS access. The karma system could be
  something like advogato's (http://www.advogato.org/trust-metric.html
  http://www.advogato.org/person/).


--Jeff

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


Re: Vicious Abuse?

Posted by Martin van den Bemt <ml...@mvdb.net>.
Costin,  

> Having hierarchies of 'people can only code' and 'people who lead' is
> not freedom. Creating a group that is 'more equal than the others' and
> taking away the right to vote to those we believe don't care is not
> freedom.

Maybe I missed something, but who as actually talking about people who
lead? Those "non committing members" will probably lead in there area
(sysadmins, legal stuff, or whatever you can think of) and they don't
care about projects at all, unless it involves their area.
I must add that I don't exactly know how this is handled right now, but
I guess if you want to put the jsdk on the tomcat site, you will get
someone -1'ing because of legal issues. I don't care about those issues,
so let people take care of what they are good at (in your case tomcat..)
Wouldn't it be great to just say "oh, let's cc xxxx, and let him/her
figure out it this is legal") and get back to focus on what really is
important. 
That person you are cc'ing could be a pro-deo lawyer and really wants to
be involved in the jakarta commity, but cannot be a member, because he
is not part of a project? You will get laught hard at if you will start
a vote to let this person be a committer, but it is better to start a
vote that he becomes a member, because he is contributing to legal
issues on jakarta.

People like to belong to something, you cannot say to people : we'll
drain your brain, but you are not an essential part of this comminity!
even though he is. The logical consequence will be he will disconnect
the brain drain and will not help us out anymore. 


Is this such a bad idea ? 

This lawyer is an example off course ;)) 


Mvgr,
Martin




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


Re: Vicious Abuse?

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> "Jeff Turner" <je...@socialchange.net.au> wrote:
> 
> > .. and thankful that people like Costin persevere in spite of rather
> > vicious abuse.
> 
> Vicious abuse? All I am proposing is to add greater flexibility to the
> freedom of those who are involved with the Jakarta project.
> 
> All I'm proposing is to accept the idea that we might have coders who don't
> care about new projects or PMCs, they just want their code done, or that we
> might have important resources out there who might want to get involved with
> this project but cannot be tied to one particular code base?
> 
> Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
> doesn¹t know how to code in C or Java, or Perl, and doesn't even know what
> CVS is all about?

There is no requirement for someone to know C or Java for becomming a 
commiter. All you need is make contributions to the project. I've seen
no language requirement ( Java or English )

We have plenty of people who don't care about politics - they just don't 
vote or are smart enough to not participate in the flame-wars. 


> Is it a vicious abuse to ask to free this community from a concept like
> "meritocracy as the number of lines of code you put into CVS"?
> 
> I don't think so, because if this community believes that "freedom" is a
> vicious abuse, this community is racist, racist towards those who can't or
> don't want to have to deal with CVS, no more and no less as one could be
> racist on the color of your skin, or the ideas that populate your mind...

Having hierarchies of 'people can only code' and 'people who lead' is
not freedom. Creating a group that is 'more equal than the others' and
taking away the right to vote to those we believe don't care is not
freedom.

Costin 


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


RE: Vicious Abuse?

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 18:22, Danny Angus wrote:
> I think what I'm trying to say is that if we want to reconcile the
> conflicting aims of having a small manageable group who can communicate, and
> *reach**decisions* easily with encouraging large number of participants it
> needs to be in some way fractal.
> 

This is why I think we need an infrastructure subproject for jakarta. 
Those who really care about what goes on site2 can join the
infrastructure project.  Those that actually contribute become
committers.

> What is there to be gained by giving every commiter access to jakarta-site2?
> or deadalus? filtering memberships & permissions and whatever else will
> strengthen, or at least not dilute, the "brand".
> 

whooa..ho ho..  Do you know what a pain it was to get the POI site up
with no direct access in the hands of any of the project committers? 
(The well meaning goal was to restrict access to the server)..  We had
to store all the generated HTML/javadoc/etc in CVS which was very
painful for our Australian committers/contributers.  While I don't think
everyone should have access, don't solve the traffic problem by shutting
down the road system.   

> Yet to encourage participation we need to have levels of membership which
> are comparativly easy to attain and bring with them some kudos.
> 

By demoting the committers?  Why that will bring them lots of warm
fuzzies.  

-Andy

> d.
> 
> 
> 
> > Naw, I like the PMC being elected by the greater body of committers.  I
> > think that keeps em honest.  There already is the ASF that functions
> > somewhat more as you say.  Jakarta is somewhat of a flat organization,
> > and I think thats a good thing.  Too many steps in the hierarchy and
> > sooner or later you have a bureaucratic unmovable body.
> >
> > -Andy
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


RE: Vicious Abuse?

Posted by Danny Angus <da...@apache.org>.
I think what I'm trying to say is that if we want to reconcile the
conflicting aims of having a small manageable group who can communicate, and
*reach**decisions* easily with encouraging large number of participants it
needs to be in some way fractal.

What is there to be gained by giving every commiter access to jakarta-site2?
or deadalus? filtering memberships & permissions and whatever else will
strengthen, or at least not dilute, the "brand".

Yet to encourage participation we need to have levels of membership which
are comparativly easy to attain and bring with them some kudos.

d.



> Naw, I like the PMC being elected by the greater body of committers.  I
> think that keeps em honest.  There already is the ASF that functions
> somewhat more as you say.  Jakarta is somewhat of a flat organization,
> and I think thats a good thing.  Too many steps in the hierarchy and
> sooner or later you have a bureaucratic unmovable body.
>
> -Andy


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


RE: Vicious Abuse?

Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Sat, 2002-05-25 at 17:40, Danny Angus wrote:
> 
> > Is it a vicious abuse to ask to free this community from a concept like
> > "meritocracy as the number of lines of code you put into CVS"?
> 
> I'm lagging behind here.. but, if you'll humor me,
> IMHO its naieve, and potentially harmful for the project to have one type of
> membership, commiters, with many seperate entrance "exams" of different
> standards.
> It also provides too much privilege in one go.
> 
> I would suggest that there be two entry levels, commiter to a sub-project
> and non-coding-member (admin) for a sub-project, neither of which carry as
> many benfits/responsibilities as the proposed next level, commiter/admin of
> whole-jakarta (like current commiters), which in turn can become "member" of
> jakarta, with "members" electing the pmc. "members" would be the elder
> statesmen, and others elevated thanks to their contribution to the
> community, not just the code, eg jon,sam, et al.
> 

Naw, I like the PMC being elected by the greater body of committers.  I
think that keeps em honest.  There already is the ASF that functions
somewhat more as you say.  Jakarta is somewhat of a flat organization,
and I think thats a good thing.  Too many steps in the hierarchy and
sooner or later you have a bureaucratic unmovable body.

-Andy

> d.
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java                            
http://krysalis.sourceforge.net/centipede - the best build/project
structure
		    a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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


RE: Vicious Abuse?

Posted by Danny Angus <da...@apache.org>.
> Is it a vicious abuse to ask to free this community from a concept like
> "meritocracy as the number of lines of code you put into CVS"?

I'm lagging behind here.. but, if you'll humor me,
IMHO its naieve, and potentially harmful for the project to have one type of
membership, commiters, with many seperate entrance "exams" of different
standards.
It also provides too much privilege in one go.

I would suggest that there be two entry levels, commiter to a sub-project
and non-coding-member (admin) for a sub-project, neither of which carry as
many benfits/responsibilities as the proposed next level, commiter/admin of
whole-jakarta (like current commiters), which in turn can become "member" of
jakarta, with "members" electing the pmc. "members" would be the elder
statesmen, and others elevated thanks to their contribution to the
community, not just the code, eg jon,sam, et al.

d.


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


RE: Vicious Abuse? (an outsiders perspective)

Posted by Martin van den Bemt <ml...@mvdb.net>.
Pier +1'ed it.
And whoever got -1'ed (sorry forgot your name), was pretty cool about
it.. (+100 on that response btw..)
Don't get me wrong, I wouldn't like it either to get -1'ed, although
there were good reasons from Pier's perspective. When he got enough
convincing arguments, he did a +1.. 
Too bad some other discussions got mixed up with this one specifically,
which clouded the request from Pier for more information about him...

Mvgr,
Martin

On Sat, 2002-05-25 at 17:22, James Mitchell wrote:
> I've been following along with this/these rather ridiculous thread's).
> 
> No, I am not a committer, so you can hit the delete key now if you judge
> people by their status.
> 
> IMHO, giving someone a -1 is one of the rudest things I have seen on this
> list in quite a while.
> What is most surprising to me, is how you stuck to your ignorant opinion,
> even after so many others were willing to vote them in.
> 
> I have no plans in the future to become a Tomcat committer, however, I do
> have my sights set on the Struts project.  I sincerely hope that there are
> no committers there who share your view on 'how to keep yourself important
> by keeping others out'.  I have seen this characteristic before in a few
> people, of whom shall remain nameless, but they know who they are.
> 
> James Mitchell
> 
> > -----Original Message-----
> > From: Pier Fumagalli [mailto:pier@betaversion.org]
> > Sent: Saturday, May 25, 2002 10:52 AM
> > To: Jakarta General List
> > Cc: Tomcat Developers List
> > Subject: Vicious Abuse?
> >
> >
> > "Jeff Turner" <je...@socialchange.net.au> wrote:
> >
> > > .. and thankful that people like Costin persevere in spite of rather
> > > vicious abuse.
> >
> > Vicious abuse? All I am proposing is to add greater flexibility to the
> > freedom of those who are involved with the Jakarta project.
> >
> > All I'm proposing is to accept the idea that we might have coders
> > who don't
> > care about new projects or PMCs, they just want their code done,
> > or that we
> > might have important resources out there who might want to get
> > involved with
> > this project but cannot be tied to one particular code base?
> >
> > Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
> > doesn¹t know how to code in C or Java, or Perl, and doesn't even know what
> > CVS is all about?
> >
> > Is it a vicious abuse to ask to free this community from a concept like
> > "meritocracy as the number of lines of code you put into CVS"?
> >
> > I don't think so, because if this community believes that "freedom" is a
> > vicious abuse, this community is racist, racist towards those who can't or
> > don't want to have to deal with CVS, no more and no less as one could be
> > racist on the color of your skin, or the ideas that populate your mind...
> >
> >     Pier (really, really worried)
> >
> > --
> > [Perl] combines all the worst aspects of C and Lisp:  a billion
> > of different
> > sublanguages in  one monolithic executable.  It combines the
> > power of C with
> > the readability of PostScript. [Jamie Zawinski - DNA Lounge - San
> > Francisco]
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



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


Re: Vicious Abuse? (an outsiders perspective)

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Anthony W. Marino" <an...@AWMObjects.com> wrote:

>> I've been following along with this/these rather ridiculous thread's).
>> 
>> No, I am not a committer, so you can hit the delete key now if you judge
>> people by their status.
>> 
>> IMHO, giving someone a -1 is one of the rudest things I have seen on this
>> list in quite a while.
>> What is most surprising to me, is how you stuck to your ignorant opinion,
>> even after so many others were willing to vote them in.
> 
> Isn't that part of the democracy of this process...call it as you see it???
> As long as you can qualify/backup your statements then I see nothing wrong
> with it.  In fact, I appreciate/welcome it as long as it is handled
> professionally and with an open mind such as Pier has demonstrated.
> Apparently Dan, too, has expressed his acceptance of Pier's thoughts!

Thank you, and I would like to close the "vote" issue here, I believe that
my vote had all the rights to be expressed. I don't use SSI, I don't know
what's wrong with it, I don't know absolutely anything about the guy who is
being proposed to fix those problems. Once he gave me his idea on how things
were, and what he wanted to do with, I suddenly changed my vote, before the
end of the ballot (3 days after proposal), and welcomed him open arms...

I don't think that saying "hold on one second, stop this thing for a while
because I don't really get it" and then "ah, ok, cool, I'm fine with it"
means being rude... Sorry if someone perceived it somehow differently.

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: Vicious Abuse? (an outsiders perspective)

Posted by "Anthony W. Marino" <an...@AWMObjects.com>.
> I've been following along with this/these rather ridiculous thread's).
>
> No, I am not a committer, so you can hit the delete key now if you judge
> people by their status.
>
> IMHO, giving someone a -1 is one of the rudest things I have seen on this
> list in quite a while.
> What is most surprising to me, is how you stuck to your ignorant opinion,
> even after so many others were willing to vote them in.

Isn't that part of the democracy of this process...call it as you see it???
As long as you can qualify/backup your statements then I see nothing wrong  
with it.  In fact, I appreciate/welcome it as long as it is handled 
professionally and with an open mind such as Pier has demonstrated.  
Apparently Dan, too, has expressed his acceptance of Pier's thoughts!


Anthony


>
> I have no plans in the future to become a Tomcat committer, however, I do
> have my sights set on the Struts project.  I sincerely hope that there are
> no committers there who share your view on 'how to keep yourself important
> by keeping others out'.  I have seen this characteristic before in a few
> people, of whom shall remain nameless, but they know who they are.
>
> James Mitchell
>
> > -----Original Message-----
> > From: Pier Fumagalli [mailto:pier@betaversion.org]
> > Sent: Saturday, May 25, 2002 10:52 AM
> > To: Jakarta General List
> > Cc: Tomcat Developers List
> > Subject: Vicious Abuse?
> >
> > "Jeff Turner" <je...@socialchange.net.au> wrote:
> > > .. and thankful that people like Costin persevere in spite of rather
> > > vicious abuse.
> >
> > Vicious abuse? All I am proposing is to add greater flexibility to the
> > freedom of those who are involved with the Jakarta project.
> >
> > All I'm proposing is to accept the idea that we might have coders
> > who don't
> > care about new projects or PMCs, they just want their code done,
> > or that we
> > might have important resources out there who might want to get
> > involved with
> > this project but cannot be tied to one particular code base?
> >
> > Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
> > doesn¹t know how to code in C or Java, or Perl, and doesn't even know
> > what CVS is all about?
> >
> > Is it a vicious abuse to ask to free this community from a concept like
> > "meritocracy as the number of lines of code you put into CVS"?
> >
> > I don't think so, because if this community believes that "freedom" is a
> > vicious abuse, this community is racist, racist towards those who can't
> > or don't want to have to deal with CVS, no more and no less as one could
> > be racist on the color of your skin, or the ideas that populate your
> > mind...
> >
> >     Pier (really, really worried)
> >
> > --
> > [Perl] combines all the worst aspects of C and Lisp:  a billion
> > of different
> > sublanguages in  one monolithic executable.  It combines the
> > power of C with
> > the readability of PostScript. [Jamie Zawinski - DNA Lounge - San
> > Francisco]
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>


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


Re: Vicious Abuse? (an outsiders perspective)

Posted by Pier Fumagalli <pi...@betaversion.org>.
"James Mitchell" <jm...@telocity.com> wrote:

> I've been following along with this/these rather ridiculous thread's).

Good...

> No, I am not a committer, so you can hit the delete key now if you judge
> people by their status.

Who said I am? I _am_ the one who is trying to modify the current status quo
so that people with different skills and interests can be part of the
Jakarta community without being tied to a CVS account.

> IMHO, giving someone a -1 is one of the rudest things I have seen on this
> list in quite a while.

Casus belli. I believe that me and Dan cleared this whole thing up and (go
and read), I've even "welcomed" him to the set of committers with CVS
account in the Tomcat project. He has my +1.

> What is most surprising to me, is how you stuck to your ignorant opinion,
> even after so many others were willing to vote them in.

My "ignorant" opinion is based on years of working within this project, is
based on making things for you all work, day by day. I don't usually point
this out, but my contributions to Jakarta are not the few lines of code I
put in Warp, but somewhere else (and those who know, know it). I might not
even be a committer if it wasn't for 2/3 patches a month, but do believe me
when I say that I spend at least 4 hours a day to do stuff for this amazing
bunch of folks.

> I have no plans in the future to become a Tomcat committer, however, I do
> have my sights set on the Struts project.  I sincerely hope that there are
> no committers there who share your view on 'how to keep yourself important
> by keeping others out'.  I have seen this characteristic before in a few
> people, of whom shall remain nameless, but they know who they are.

"Keep meself important by keeping others out" ??? I welcomed Dan to the
community, and _actually_ what I'm trying to do, is to offer a greater deal
of freedom to this community as a whole, for people who CODE, and for people
who DON'T...

    Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


RE: Vicious Abuse? (an outsiders perspective)

Posted by James Mitchell <jm...@telocity.com>.
I've been following along with this/these rather ridiculous thread's).

No, I am not a committer, so you can hit the delete key now if you judge
people by their status.

IMHO, giving someone a -1 is one of the rudest things I have seen on this
list in quite a while.
What is most surprising to me, is how you stuck to your ignorant opinion,
even after so many others were willing to vote them in.

I have no plans in the future to become a Tomcat committer, however, I do
have my sights set on the Struts project.  I sincerely hope that there are
no committers there who share your view on 'how to keep yourself important
by keeping others out'.  I have seen this characteristic before in a few
people, of whom shall remain nameless, but they know who they are.

James Mitchell

> -----Original Message-----
> From: Pier Fumagalli [mailto:pier@betaversion.org]
> Sent: Saturday, May 25, 2002 10:52 AM
> To: Jakarta General List
> Cc: Tomcat Developers List
> Subject: Vicious Abuse?
>
>
> "Jeff Turner" <je...@socialchange.net.au> wrote:
>
> > .. and thankful that people like Costin persevere in spite of rather
> > vicious abuse.
>
> Vicious abuse? All I am proposing is to add greater flexibility to the
> freedom of those who are involved with the Jakarta project.
>
> All I'm proposing is to accept the idea that we might have coders
> who don't
> care about new projects or PMCs, they just want their code done,
> or that we
> might have important resources out there who might want to get
> involved with
> this project but cannot be tied to one particular code base?
>
> Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
> doesn¹t know how to code in C or Java, or Perl, and doesn't even know what
> CVS is all about?
>
> Is it a vicious abuse to ask to free this community from a concept like
> "meritocracy as the number of lines of code you put into CVS"?
>
> I don't think so, because if this community believes that "freedom" is a
> vicious abuse, this community is racist, racist towards those who can't or
> don't want to have to deal with CVS, no more and no less as one could be
> racist on the color of your skin, or the ideas that populate your mind...
>
>     Pier (really, really worried)
>
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion
> of different
> sublanguages in  one monolithic executable.  It combines the
> power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San
> Francisco]
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>



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


Re: Vicious Abuse?

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> "Jeff Turner" <je...@socialchange.net.au> wrote:
> 
> > .. and thankful that people like Costin persevere in spite of rather
> > vicious abuse.
> 
> Vicious abuse? All I am proposing is to add greater flexibility to the
> freedom of those who are involved with the Jakarta project.
> 
> All I'm proposing is to accept the idea that we might have coders who don't
> care about new projects or PMCs, they just want their code done, or that we
> might have important resources out there who might want to get involved with
> this project but cannot be tied to one particular code base?
> 
> Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
> doesn¹t know how to code in C or Java, or Perl, and doesn't even know what
> CVS is all about?

There is no requirement for someone to know C or Java for becomming a 
commiter. All you need is make contributions to the project. I've seen
no language requirement ( Java or English )

We have plenty of people who don't care about politics - they just don't 
vote or are smart enough to not participate in the flame-wars. 


> Is it a vicious abuse to ask to free this community from a concept like
> "meritocracy as the number of lines of code you put into CVS"?
> 
> I don't think so, because if this community believes that "freedom" is a
> vicious abuse, this community is racist, racist towards those who can't or
> don't want to have to deal with CVS, no more and no less as one could be
> racist on the color of your skin, or the ideas that populate your mind...

Having hierarchies of 'people can only code' and 'people who lead' is
not freedom. Creating a group that is 'more equal than the others' and
taking away the right to vote to those we believe don't care is not
freedom.

Costin 


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


Vicious Abuse?

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Turner" <je...@socialchange.net.au> wrote:

> .. and thankful that people like Costin persevere in spite of rather
> vicious abuse.

Vicious abuse? All I am proposing is to add greater flexibility to the
freedom of those who are involved with the Jakarta project.

All I'm proposing is to accept the idea that we might have coders who don't
care about new projects or PMCs, they just want their code done, or that we
might have important resources out there who might want to get involved with
this project but cannot be tied to one particular code base?

Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
doesn¹t know how to code in C or Java, or Perl, and doesn't even know what
CVS is all about?

Is it a vicious abuse to ask to free this community from a concept like
"meritocracy as the number of lines of code you put into CVS"?

I don't think so, because if this community believes that "freedom" is a
vicious abuse, this community is racist, racist towards those who can't or
don't want to have to deal with CVS, no more and no less as one could be
racist on the color of your skin, or the ideas that populate your mind...

    Pier (really, really worried)

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Vicious Abuse?

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Turner" <je...@socialchange.net.au> wrote:

> .. and thankful that people like Costin persevere in spite of rather
> vicious abuse.

Vicious abuse? All I am proposing is to add greater flexibility to the
freedom of those who are involved with the Jakarta project.

All I'm proposing is to accept the idea that we might have coders who don't
care about new projects or PMCs, they just want their code done, or that we
might have important resources out there who might want to get involved with
this project but cannot be tied to one particular code base?

Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she
doesn¹t know how to code in C or Java, or Perl, and doesn't even know what
CVS is all about?

Is it a vicious abuse to ask to free this community from a concept like
"meritocracy as the number of lines of code you put into CVS"?

I don't think so, because if this community believes that "freedom" is a
vicious abuse, this community is racist, racist towards those who can't or
don't want to have to deal with CVS, no more and no less as one could be
racist on the color of your skin, or the ideas that populate your mind...

    Pier (really, really worried)

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, May 25, 2002 at 02:04:24PM +0100, Pier Fumagalli wrote:
> costinm@covalent.net <co...@covalent.net> wrote:
> > On Sat, 25 May 2002, Pier Fumagalli wrote:
> > 
> >>> If you are a commiter - you have the same rights with all other commiters.
> >>> If you don't want to exercise some rights - it's your choice.
> >> 
> >> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
> >> only "rights"... It's also "dues", right?
> > 
> > Yes, the 'due' to spend weekends writing code or answering emails or
> > reading flame wars.
> > 
> > Give me a break with the big 'due' to vote or have a say over how the
> > project you're involved with.
> 
> And in fact, Costin, the big opposition you're going to get from me, will
> always be on the fact that you are totally and utterly irresponsible towards
> this community and the ASF... It's years that you're been told that, not
> only from me, but from an extended number of people (do we want to get back
> to the Tomcat 3.x/4.x flamewar? Read those comments)...

Aren't we all happy that 3.3.x exists, and is better than 3.2.x? Aren't
we all happy that we have a choice to 4.x?

Aren't we all happy that Jon was 'mislead' into not -1'ing Struts (one
of Jakarta's biggest successes)?

Perhaps people should be less certain they know what is best for the
community :P

> Anyway, nice talking to you (not).

.. and thankful that people like Costin persevere in spite of rather
vicious abuse.


--Jeff
(a happy 3.3.x and Struts user, whose sense of justice temporarily
outweighs an aversion to general@ flamewars)


>     Pier
> 

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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Sat, 25 May 2002, Pier Fumagalli wrote:
> 
>>> If you are a commiter - you have the same rights with all other commiters.
>>> If you don't want to exercise some rights - it's your choice.
>> 
>> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
>> only "rights"... It's also "dues", right?
> 
> Yes, the 'due' to spend weekends writing code or answering emails or
> reading flame wars.
> 
> Give me a break with the big 'due' to vote or have a say over how the
> project you're involved with.

And in fact, Costin, the big opposition you're going to get from me, will
always be on the fact that you are totally and utterly irresponsible towards
this community and the ASF... It's years that you're been told that, not
only from me, but from an extended number of people (do we want to get back
to the Tomcat 3.x/4.x flamewar? Read those comments)...

Anyway, nice talking to you (not).

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Sat, 25 May 2002, Pier Fumagalli wrote:
> 
>>> If you are a commiter - you have the same rights with all other commiters.
>>> If you don't want to exercise some rights - it's your choice.
>> 
>> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
>> only "rights"... It's also "dues", right?
> 
> Yes, the 'due' to spend weekends writing code or answering emails or
> reading flame wars.
> 
> Give me a break with the big 'due' to vote or have a say over how the
> project you're involved with.

And in fact, Costin, the big opposition you're going to get from me, will
always be on the fact that you are totally and utterly irresponsible towards
this community and the ASF... It's years that you're been told that, not
only from me, but from an extended number of people (do we want to get back
to the Tomcat 3.x/4.x flamewar? Read those comments)...

Anyway, nice talking to you (not).

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> > If you are a commiter - you have the same rights with all other commiters.
> > If you don't want to exercise some rights - it's your choice.
> 
> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
> only "rights"... It's also "dues", right?

Yes, the 'due' to spend weekends writing code or answering emails or 
reading flame wars. 

Give me a break with the big 'due' to vote or have a say over how the 
project you're involved with. 


Costin 



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
On Sat, 25 May 2002, Pier Fumagalli wrote:

> > If you are a commiter - you have the same rights with all other commiters.
> > If you don't want to exercise some rights - it's your choice.
> 
> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
> only "rights"... It's also "dues", right?

Yes, the 'due' to spend weekends writing code or answering emails or 
reading flame wars. 

Give me a break with the big 'due' to vote or have a say over how the 
project you're involved with. 


Costin 



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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:

> I do agree ( and I advocated for this a lot ) on lowering ( or
> eliminating) the walls between projects, so jakarta commiters can commit
> code in any jakarta project ( subject to the normal project rules ).
> Some people didn't agree with that even for commons, and I accepted the
> fact. 

Over my dead body.

> If you are a commiter - you have the same rights with all other commiters.
> If you don't want to exercise some rights - it's your choice.

Hola, you tend to forget a part I'm stressing out quite hardly... It's not
only "rights"... It's also "dues", right?

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:

> I do agree ( and I advocated for this a lot ) on lowering ( or
> eliminating) the walls between projects, so jakarta commiters can commit
> code in any jakarta project ( subject to the normal project rules ).
> Some people didn't agree with that even for commons, and I accepted the
> fact. 

Over my dead body.

> If you are a commiter - you have the same rights with all other commiters.
> If you don't want to exercise some rights - it's your choice.

Hola, you tend to forget a part I'm stressing out quite hardly... It's not
only "rights"... It's also "dues", right?

    Pier


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
-1

If someone doesn't want to be involved in the voting - he can do exaclty
that, abstain. If someone doesn't want to support a particular release -
he can abstain from the release vote( or vote +-0 ). 

If you spend time and write code for a project and are willing to
maintain/support - and if the people on the project vote you in, 
you have the same rights as all the other people on that project.


I do agree ( and I advocated for this a lot ) on lowering ( or 
eliminating) the walls between projects, so jakarta commiters can commit 
code in any jakarta project ( subject to the normal project rules ).
Some people didn't agree with that even for commons, and I accepted the
fact. 

If you are a commiter - you have the same rights with all other commiters.
If you don't want to exercise some rights - it's your choice. 



Costin



On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
> 
> So the major topic of discussion is that I perceive a substantial difference
> between being able to commit code to a CVS repository, and being a
> "committer" committer, with all dues and responsibilities that this role
> concerns...
> 
> For example sometimes someone might want to have commit access just because
> he is working for a company that deals with a particular project in Apache
> (we've seen this happening several times with some projects such as Xerces
> and Tomcat), but he really doesn't care about the whole fuzz of Apache and
> stuff, and once the employment contract ends, the relationship with Apache
> terminates as well (I don't need to enumerate all those examples along those
> lines).
> 
> One other example, if we didn't have Henri building RPMs for basically all
> Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> don't you think that he would deserve committer status even if he's not tied
> to any particular codebase? We had this "problem" in the current election of
> the members, Sally Khudairi: Sally doesn't code, but she was involved with
> the ASF since before it was even created as a press organizer. Does she
> deserve to be a member of the foundation? Even if she doesn't code? Yes she
> does, IMO (and she was elected and nominated a member today)...
> 
> So, IMO, there's a great difference between being a coder, and being a
> member of the Jakarta community, at least in my opinion. There might be
> coders who are not involved with the community, and there might be
> non-coders who are much involved with it, want to participate, are active
> and deserve to be committers...
> 
> Our current structure doesn't "allow" that to happen, both things. If you
> need to write code in a particular source-base, and you need CVS access, you
> are automagically made a committer, even if you don't care about much else,
> and if you're very much involved with the overall project, but not tied to
> ANY whatsoever codebase, and really, don't want / can't do it.
> 
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
> 
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
> 
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
> 
> And redefining the figure of the "committer" as follows:
> 
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
> 
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?
> 
>     Pier
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by co...@covalent.net.
-1

If someone doesn't want to be involved in the voting - he can do exaclty
that, abstain. If someone doesn't want to support a particular release -
he can abstain from the release vote( or vote +-0 ). 

If you spend time and write code for a project and are willing to
maintain/support - and if the people on the project vote you in, 
you have the same rights as all the other people on that project.


I do agree ( and I advocated for this a lot ) on lowering ( or 
eliminating) the walls between projects, so jakarta commiters can commit 
code in any jakarta project ( subject to the normal project rules ).
Some people didn't agree with that even for commons, and I accepted the
fact. 

If you are a commiter - you have the same rights with all other commiters.
If you don't want to exercise some rights - it's your choice. 



Costin



On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
> 
> So the major topic of discussion is that I perceive a substantial difference
> between being able to commit code to a CVS repository, and being a
> "committer" committer, with all dues and responsibilities that this role
> concerns...
> 
> For example sometimes someone might want to have commit access just because
> he is working for a company that deals with a particular project in Apache
> (we've seen this happening several times with some projects such as Xerces
> and Tomcat), but he really doesn't care about the whole fuzz of Apache and
> stuff, and once the employment contract ends, the relationship with Apache
> terminates as well (I don't need to enumerate all those examples along those
> lines).
> 
> One other example, if we didn't have Henri building RPMs for basically all
> Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> don't you think that he would deserve committer status even if he's not tied
> to any particular codebase? We had this "problem" in the current election of
> the members, Sally Khudairi: Sally doesn't code, but she was involved with
> the ASF since before it was even created as a press organizer. Does she
> deserve to be a member of the foundation? Even if she doesn't code? Yes she
> does, IMO (and she was elected and nominated a member today)...
> 
> So, IMO, there's a great difference between being a coder, and being a
> member of the Jakarta community, at least in my opinion. There might be
> coders who are not involved with the community, and there might be
> non-coders who are much involved with it, want to participate, are active
> and deserve to be committers...
> 
> Our current structure doesn't "allow" that to happen, both things. If you
> need to write code in a particular source-base, and you need CVS access, you
> are automagically made a committer, even if you don't care about much else,
> and if you're very much involved with the overall project, but not tied to
> ANY whatsoever codebase, and really, don't want / can't do it.
> 
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
> 
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
> 
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
> 
> And redefining the figure of the "committer" as follows:
> 
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
> 
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?
> 
>     Pier
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


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


Re: [PROPOSAL] Committer access and responsibilities...

Posted by Henri Yandell <ba...@generationjava.com>.
+1.

Another example if I could. The job role of 'Java admin' is growing more
and more at companies. Developers shouldn't be adminning things, but would
you have your unix or oracle admin be the admin of the Java side with zero
Java knowledge?

Jakarta houses the 'Java' community at Apache but there's no way for a
Java admin to be a part of that community. Helping other admins, writing
documentation, being a consumer at the coders. The only way it can happen
is if they become a coder, and that's contrary to the concept of a Java
admin.

I think Pier's suggestion will help to grow the 'ownership' of the
projects and the apache way of thinking to a larger audience.

Some possible negatives:

With more non-codery people around, will the 'noise' level in mail lists
be too high for coders to want to pay attention?
[It already is getting that way I find. I delete entire threads if the
first couple of mails are not of interest to me. It has to be retitled as
with this email to make me realise there was more going on than the
original mails. ]

By growing a large community of non-coders, the coders could have less say
in the product. Is this good/bad? How would the +1/-1 system work. Would
votes be open to committers only in some instances, and to non-committing
members only in others. Who votes membership vs committership vs
contributorship?


None of them that hard to answer I imagine.

Hen

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
>
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
>
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
>
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
>
> And redefining the figure of the "committer" as follows:
>
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
>


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