Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <00ce01c3ca4d$bfb7eb60$754d8151@oemcomputer>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <3FE86348.5090406@steitz.com>
 <Pine.LNX.4.44.0312231100490.31937-100000@umbongo.flamefew.net>
 <20031223174935.B7414@lyra.org> <20031223232655.Y44052@minotaur.apache.org>
Subject: Commons people layers [wasRe: [plea] get back to work]
Date: Wed, 24 Dec 2003 18:42:56 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The normal ASF structure appears to be:
- User
- Contributor
- Committer
- PMC member
- ASF member

I would suggest that for J-C there is another level:
- User
- Contributor
- InterestedParty
- Committer
- PMC member
- ASF member

I've deliberately used a psuedo name 'InterestedParty' as the correct name
may need debate. An attempt to describe the role of this layer is
"committers or PMC members who are not active committers on the component,
but do have an active interest".

This layer is quite interesting, in that the people can help guide the
component, provide advice, vote on releases etc in many of the ways that an
active committer can. They do not have the right to block changes to the
component however, nor (in this case) block a move to A-C.

I would posit that it is this layer that makes J-C work, because without it
no single component could survive.

Note, the main downsides to this are that its not codified, and sometimes
the interested parties can surprise you when they intervene ;-)
Stephen

----- Original Message -----
From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> On Tue, 23 Dec 2003, Greg Stein wrote:
>
> > It doesn't really matter was is listed. What is the actual truth is that
> > there are only two committers on the thing: ggregory and tobrian.
> > The others are happenstance.
>
> That statement is simply not accurate.  There are at least four folks who
> have made commits at its current location.  There are seven folks who have
> made commits at its previous location (commons-sandbox).  A quick grep
> for @author tags indicates that there are quite a number of hands in this
> body of work.
>
> As you may be aware, the Base64 implementation in particular has quite a
> rich history at Jakarta--it has been cut-and-pasted, shared and mutated in
> quite a number of projects, at least including, Ant, Slide, and
> Commons-HttpClient and now Commons-Codec.  Bugfixes and changes have been
> back-ported and forward-ported between a number of these mutations. It's a
> vertiable case study of "reuse", in all it's forms, at Jakarta.  If all
> you've done is a "cvs log" on the current codec repository, you're missing
> most of the picture here.
>
> > > > I have never seen an example where a commons
> > > > developer (committer or not) is unable to "do what they want...with
the
> > > > code that interests them" because of community fragmentation.
> >
> > It isn't fragmentation. It is people asserting ownership over something
> > they are not involved with. Tim said, "I'd like to move this to A-C" and
> > people who are really not involved with the codebase are saying "no".
One
> > of the two who are closest is thus denied what he believes is best for
the
> > codebase.
>
> I'll assume you are referring to my vote.  This statement is also
> inaccurate, in at least two ways:
>
> 1) I didn't "assert ownership" over anything.  I stated my -1 opinion on a
> majority vote thread.  Moreover, I explictly stated that if others wanted
> to view this as a consensus vote, I'd change my vote to -0, hence not
> "denying" anyone anything.
>
> 2) I have been involved with this code and this component, in a number of
> ways, over an extended period of time.  I may not have contributed
> as much as some others, notably Greg (G.) and Tim, but as I understand
> it, we're not a "some animals are more equal than others" kind of
> place, at least officially.  Unofficially, see #1.
>
> I believe moving codec to apache commons at this time is a mistake. I'm
> entitled to my opinion in the matter.  I'm also entitled to express it.
>
> > [ all that said, note that this is for example purposes only. the other
> >   committer on code, ggregory, voted against moving, so tobrian dropped
> >   the suggestion;
>
> Right, so what's your point again?
>
> > however, if the two of them *had* said "let's move", it
> >   sure looked like J-C was going to try and stop it ]
>
> I don't believe that to be the case.  It would be the first time that the
> jakarta commons committers as a whole acted against the wishes of the
> developers of a particular component.
>
> > Note: I'm not asserting that A-C solves this. My point was focused
around
> > (IMO) improper assertions of "ownership" (if you will) over components
and
> > their destinies.
>
> Please point to something "improper", or drop the assertion.
>
> > The second point was that I feel that J-C isn't quite as
> > unified as some may believe, by virtue of the small dev subgroups.
>
> No one said it was "unified", did they?
>
> > Cheers,
> > -g
>
> --
> - Rod <http://radio.weblogs.com/0122027/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org