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>
Date: Tue, 23 Dec 2003 22:00:59 -0800
From: Greg Stein <gstein@lyra.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [plea] get back to work
Message-ID: <20031223220059.D7414@lyra.org>
References: <3FE86348.5090406@steitz.com>
 <Pine.LNX.4.44.0312231100490.31937-100000@umbongo.flamefew.net>
 <20031223174935.B7414@lyra.org> <3FE90D37.3090701@steitz.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3FE90D37.3090701@steitz.com>;
 from phil@steitz.com on Tue, Dec 23, 2003 at 08:51:19PM -0700

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