commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [plea] get back to work
Date Wed, 24 Dec 2003 03:51:19 GMT
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:
>>>>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.
>>>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 :-).

> Cheers,
> -g

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message