Re: [plea] get back to work

[Greg Stein <gs...@lyra.org>]

On Tue, Dec 23, 2003 at 10:59:02AM +0000, Danny Angus wrote:
>...
> > I'll say again - the Board could avoid this damage by
> > choosing to ACT rather than REACT.
> 
> It is extremely unlikely that the board will become involved in this unless
> either the PMC request it or it directly affects the board's business. The
> right people to decide the future of Jakarta commons are the Jakarta
> commons commiters.

While it might be nice to request help from "The Man", I seriously doubt
that will happen. As Danny put it: this is something for Jakarta to work
out, not for the Board to step in and deal with.

Generally speaking, the Board has two positions:

1) the Project is not damaging the ASF (but note it might not actually be
   making progress, but the ASF doesn't *require* forward progress)
   
   --> leave it alone and let it work out whatever issues it feels it has


2) the Project *is* damaging the ASF

   --> shut it down


There isn't a lot of middle ground for the Board to work within because it
doesn't know the Right Answer for the given community. What would happen
if the Board started thinking it *did* know and began to interfere with
the operation of the Projects throughout the ASF. Chaos. Revolt. :-)

That's my personal position with my Director's hat on. I'll posit that it
is also pretty close to the rest of the Board's position. Also note that
the Board is pretty conservative. Things have got to get pretty bad before
we take an action such as (2). I couldn't even conceive of shutting down
Jakarta; that kind of action would be more likely for smaller or newer
PMCs rather than something like Jakarta. (although I will say that things
like the cornerstone contribution peeve me immensely)

That said, the Board *will* convey directives PMCs about concerns it may
have. For example, a lot of the current traffic on the Jakarta PMC and the
action on achieving better oversight is because the Board said it didn't
feel that the PMC was providing effective oversight over such a large
codebase (hundreds of committers and how many hundreds of thousands of
lines of code?). Further, that the PMC in its current form is incapable of
doing so. Expanding the PMC might do it, but the simple fact is that
Jakarta is composed of many communities; many of them are more than
capable of handling themselves as a TLP (much as Stephen points out).
Shifting those will go a long ways towards validating that oversight is
possible and is present.

How does J-C fit into this? What I see is a loosely knit group of
developers each working on one or more components. There is definitely a
feeling of community, but the codebases and the people working on them
form discrete subgroups. As an easy example: the codec component really
only has two committers on it. I'm not sure that constitutes a problem,
but it also seems to indicate that the community != interested developers
which means that those developers cannot necessarily do what they want
(or believe is best) with the code that interests them.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

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

Re: [plea] get back to work

[Greg Stein <gs...@lyra.org>]

On Tue, Dec 23, 2003 at 08:51:19PM -0700, Phil Steitz wrote:
> Greg Stein wrote:
>...
> > Now people might say, "but we *are* involved. we watch the commits, we
> > talk about them, etc etc, but we just don't commit ourselves." That
> > ability will not disappear by virtue of the fact that the person(s) who
> > *are* doing all the work feel it is best to move that work elsewhere. You
> > can still sign up for the commits and participate in the dev discussions.
> > It just happens to be somewhere better for the codebase.
> 
> The problem is that if this means subscribing to lots of little lists, 
> many of us won't do it and that will not be "better for the codebase." 
> See Martin Cooper's post on the [codec] thread.

While I understand the point, I'm not sure that I entirely agree. If a
person is really involved with a codebase, then they will put in some
effort to participate. Casual observers will be lost: that I agree. And
does that also imply some loss of peer review. Sure.

The real question, which is entirely subjective and something we can't
really answer is: what is the balance of benefit/loss? Net positive? Or
net negative? If moving a codebase is felt to be best, but comes at some
small amount of loss of peer review, then do have an overall benefit?

Throw in some of the larger issues such as: is there a direct chain of
oversight from the committers up to the ASF Board? are the rules and
policies healthy? should the codebase spin to its own TLP? etc

And back to the "little lists": if you move a codebase to a TLP, then
you're going to end up with a (hopefully) "big" list, and one that is
entirely focused on the subject which interests you. I think the "little
list" concept translates more into moving from one commons to another
(whether that is A-C or DB-C or whatever).

> > [ 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; 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 disagree here as well.  Only Rodney (one of the codec committers) voted 
> -1, and he qualified it with a statement that he could be persuaded to 
> change to -0 if the others felt strongly enough.

I also read a number of "all or nothing" posts which I read as somewhere
between -0 and -1. I think "stop it" may have been overstating things :-),
but from an (admittedly) outside position, it didn't look entirely
supportive of the committers' desires.

>...
> > Thus, my original post noting that the community != developers for (many?)
> > components in J-C. That would seem like it can lead to problems.
> 
> And what might these problems be?

What I was talking about: where the committers may want to do something to
or with the codebase, but the community disagrees with them.

> What exactly do you mean by 
> "developers?"  Hopefully not "committers" since that would rule out users 
> and contributors who are not committers.

Yes, I mean the committers.

The simple fact is that it is the PMC which is responsible for the
codebase. In an ideal environment, the PMC matches up with the committers,
so the net is that it is the committers who are *responsible* for the
code. The committers decide what to do with it, what development
directions it should go in, when releases are made... *everything*.

Yes, there is a larger community, but non-committers do not have a vote.
Even more strongly: they should *not* have a (binding) vote.

[ note that there is also a notion of a committer who is not on the PMC;
  that committer may be modifying the codebase, but they aren't
  responsible for it. they don't get binding votes, and all changes must
  be explicitly reviewed by a PMC member (thus ensuring that all change is
  "performed" at the direction of PMC) ]

One of the reasons why I've been advocating the removal of all
intra-Project commit barriers (e.g. some people can commit to
jakarta-commons but not to jakarta-tomcat) is because the PMC *is*
responsible for all that code. And if you're on the PMC, then your
obligation is to care for all of that code. That means full-on access. No
barrier.

J-C operates with no barriers (mostly; there is a barrier between the
sandbox and J-C proper), but Jakarta does not. A-C "will" operate like
that (I don't think we ever closed on that particular policy point).

Now... I do recognize that if you blend all those points together, you end
up with "J-C committers can change everything, and since committers define
what happens to each component, then J-C as a whole decides on what to do
with each thing." Yup, true from structural standpoint. But it doesn't
necessarily hold at a social level. At a social level, there are actually
some lines between components, and there is a traded and earned respect
for people who fall within the various areas. These are the "subgroups"
that I've mentioned.

> If what is bothering you is that 
> j-c developers are influenced by other j-c developers, then I see that as 
> a strength and I have never seen anyone complain about it.

That certainly doesn't bother me. Not sure where that came from :-)

> > 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.
> 
> I did not see this in the [codec] discussion and I have not seen it 
> elsewhere.  Maybe I am naive (really).

I discussed it a bit above, but it could also be marked up to (my) reading
a bit much into the discussion on that thread.  *shrug*

> > 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.
> 
> Here again, I disagree.  Look at the recent posts on [cache] for example, 
> or tim's post on [betwixt].  These are examples of the larger community 
> contributing to / accepting responsibility for (not "claiming ownership" 
> over) j-c components.  Both of these components need a little help right 
> now and both would (IMHO) be effectively dead if they were not part of j-c 
> (OK maybe cache is a zombie now, but there a signs of life :-).

Agreed. But I don't think that negates the points about the people having
a stake or investment in a codebase. I think there are subgroups, and it
happens that those two have zero-size groups :-). But no matter how you
shake that down: yes, there is a larger community.


Hmm. I'm feeling that this email is getting into nit-picky subtleties. I
don't want to feel like I'm arguing points to death :-( ... instead, I
just hope that some ideas or some thinking is generated from my emails.
While I don't want to rebut and run, I'll try to keep further replies a
bit shorter :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

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

Re: [plea] get back to work

[Phil Steitz <ph...@steitz.com>]

Greg Stein wrote:
> On Tue, Dec 23, 2003 at 11:01:44AM -0500, Henri Yandell wrote:
> 
>>On Tue, 23 Dec 2003, Phil Steitz wrote:
>>
>>>Greg Stein wrote:
>>><snip>
>>>
>>>>How does J-C fit into this? What I see is a loosely knit group of
>>>>developers each working on one or more components. There is definitely a
>>>>feeling of community, but the codebases and the people working on them
>>>>form discrete subgroups. As an easy example: the codec component really
>>>>only has two committers on it. I'm not sure that constitutes a problem,
>>>>but it also seems to indicate that the community != interested developers
>>>>which means that those developers cannot necessarily do what they want
>>>>(or believe is best) with the code that interests them.
>>>
>>>I disagree.  The "discrete subgroups" are very fluid and there is a lot of
>>>interaction and cross-pollination among them.  Codec in fact has 8 people
>>>listed as "committers."
> 
> 
> 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.
> 
I would not use that term ("happenstance") and I think you are missing the 
point.  See below.
> 
>>>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.

Now I understand what you meant, but I don't agree.  I think the 
discussion on the thread brought out some key issues relevant to "what is 
best for the codebase."  Gary and Tim are free to do what they want with 
[codec] -- no one is stopping them.
> 
> Now people might say, "but we *are* involved. we watch the commits, we
> talk about them, etc etc, but we just don't commit ourselves." That
> ability will not disappear by virtue of the fact that the person(s) who
> *are* doing all the work feel it is best to move that work elsewhere. You
> can still sign up for the commits and participate in the dev discussions.
> It just happens to be somewhere better for the codebase.

The problem is that if this means subscribing to lots of little lists, 
many of us won't do it and that will not be "better for the codebase." 
See Martin Cooper's post on the [codec] thread.

> 
> [ 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; 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 disagree here as well.  Only Rodney (one of the codec committers) voted 
-1, and he qualified it with a statement that he could be persuaded to 
change to -0 if the others felt strongly enough.
> 
> 
>>>Sometimes
>>>people disagree and some ideas are rejected by the community, but there is
>>>nothing stopping any developer from getting involved in any commons
>>>component.  There are also *lots* more people than the [codec] committers
>>>who read and comment on [codec] posts.
> 
> 
> This can happen anywhere in the ASF. That is the core of how the ASF
> operates.
> 
> 
>>...
>>I try to stay on top of all of the 'Children of Utils' components, which
>>includes codec. I was surprised that I've only made the one commit to
>>codec in its current cvs location.
> 
> 
> Thus, my original post noting that the community != developers for (many?)
> components in J-C. That would seem like it can lead to problems.

And what might these problems be?  What exactly do you mean by 
"developers?"  Hopefully not "committers" since that would rule out users 
and contributors who are not committers.  If what is bothering you is that 
j-c developers are influenced by other j-c developers, then I see that as 
a strength and I have never seen anyone complain about it.
> 
> 
> 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.

I did not see this in the [codec] discussion and I have not seen it 
elsewhere.  Maybe I am naive (really).

  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.

Here again, I disagree.  Look at the recent posts on [cache] for example, 
or tim's post on [betwixt].  These are examples of the larger community 
contributing to / accepting responsibility for (not "claiming ownership" 
over) j-c components.  Both of these components need a little help right 
now and both would (IMHO) be effectively dead if they were not part of j-c 
(OK maybe cache is a zombie now, but there a signs of life :-).

Phil
> 
> Cheers,
> -g
> 



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

Commons people layers [wasRe: [plea] get back to work]

[Stephen Colebourne <sc...@btopenworld.com>]

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" <rw...@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

Re: [plea] get back to work

[Rodney Waldhoff <rw...@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

Re: [plea] get back to work

[Greg Stein <gs...@lyra.org>]

On Tue, Dec 23, 2003 at 11:01:44AM -0500, Henri Yandell wrote:
> On Tue, 23 Dec 2003, Phil Steitz wrote:
> > Greg Stein wrote:
> > <snip>
> > > How does J-C fit into this? What I see is a loosely knit group of
> > > developers each working on one or more components. There is definitely a
> > > feeling of community, but the codebases and the people working on them
> > > form discrete subgroups. As an easy example: the codec component really
> > > only has two committers on it. I'm not sure that constitutes a problem,
> > > but it also seems to indicate that the community != interested developers
> > > which means that those developers cannot necessarily do what they want
> > > (or believe is best) with the code that interests them.
> >
> > I disagree.  The "discrete subgroups" are very fluid and there is a lot of
> > interaction and cross-pollination among them.  Codec in fact has 8 people
> > listed as "committers."

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.

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

Now people might say, "but we *are* involved. we watch the commits, we
talk about them, etc etc, but we just don't commit ourselves." That
ability will not disappear by virtue of the fact that the person(s) who
*are* doing all the work feel it is best to move that work elsewhere. You
can still sign up for the commits and participate in the dev discussions.
It just happens to be somewhere better for the codebase.

[ 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; however, if the two of them *had* said "let's move", it
  sure looked like J-C was going to try and stop it ]

> > Sometimes
> > people disagree and some ideas are rejected by the community, but there is
> > nothing stopping any developer from getting involved in any commons
> > component.  There are also *lots* more people than the [codec] committers
> > who read and comment on [codec] posts.

This can happen anywhere in the ASF. That is the core of how the ASF
operates.

>...
> I try to stay on top of all of the 'Children of Utils' components, which
> includes codec. I was surprised that I've only made the one commit to
> codec in its current cvs location.

Thus, my original post noting that the community != developers for (many?)
components in J-C. That would seem like it can lead to problems.


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

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

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

Re: [plea] get back to work

[Henri Yandell <ba...@generationjava.com>]

On Tue, 23 Dec 2003, Phil Steitz wrote:

> Greg Stein wrote:
> <snip>
> >
> > How does J-C fit into this? What I see is a loosely knit group of
> > developers each working on one or more components. There is definitely a
> > feeling of community, but the codebases and the people working on them
> > form discrete subgroups. As an easy example: the codec component really
> > only has two committers on it. I'm not sure that constitutes a problem,
> > but it also seems to indicate that the community != interested developers
> > which means that those developers cannot necessarily do what they want
> > (or believe is best) with the code that interests them.
>
> I disagree.  The "discrete subgroups" are very fluid and there is a lot of
> interaction and cross-pollination among them.  Codec in fact has 8 people
> listed as "committers."  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.  Sometimes
> people disagree and some ideas are rejected by the community, but there is
> nothing stopping any developer from getting involved in any commons
> component.  There are also *lots* more people than the [codec] committers
> who read and comment on [codec] posts.

Yep.

I try to stay on top of all of the 'Children of Utils' components, which
includes codec. I was surprised that I've only made the one commit to
codec in its current cvs location.

Hen


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

Re: [plea] get back to work

[Phil Steitz <ph...@steitz.com>]

Greg Stein wrote:
<snip>
> 
> How does J-C fit into this? What I see is a loosely knit group of
> developers each working on one or more components. There is definitely a
> feeling of community, but the codebases and the people working on them
> form discrete subgroups. As an easy example: the codec component really
> only has two committers on it. I'm not sure that constitutes a problem,
> but it also seems to indicate that the community != interested developers
> which means that those developers cannot necessarily do what they want
> (or believe is best) with the code that interests them.

I disagree.  The "discrete subgroups" are very fluid and there is a lot of 
interaction and cross-pollination among them.  Codec in fact has 8 people 
listed as "committers."  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.  Sometimes 
people disagree and some ideas are rejected by the community, but there is 
nothing stopping any developer from getting involved in any commons 
component.  There are also *lots* more people than the [codec] committers 
who read and comment on [codec] posts.

Phil
> 
> Cheers,
> -g
> 



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