commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthan we thought...)
Date Tue, 29 Oct 2002 23:22:08 GMT
On 10/29/02 4:04 PM, "Costin Manolache" <> wrote:

> On Tue, 2002-10-29 at 12:13, Geir Magnusson Jr. wrote:
>> Great.  Perfect description.  Not disputing the general sentiment (I still
>> think it's moving deck chairs around if you move every committer into the
>> PMC).
> I think it's more about a consistent naming and organization with the
> rest of apache ( and the httpd project where all things started ).

Ok - that's fine.  But note that httpd and jakarta are different (for what I
know of httpd...).  I don't think Jakarta is all bad, and think that changes
should be made to improve things.

> It is also a good opportunity to improve few things:
> - find who's tracking what component.

That would be good, but don't we know that from the status files ?

> - better tracking of who's active ( if we use 'active committer' def. )

How?  Once on the PMC, your are on, right?

> - a way to better pass the message and get people involved in the
> monitoring activity

I don't see how a new title and mail list will change anything.  If we have
to start changing the values of the community, we can do it directly.  If
there are things we have to change, it's our responsibility as committers to
do it.  
> My view was a global 'SPMC' file listing all the people _and_ the
> components he's volunteering to monitor ( even if he's not actively
> working on it ). STATUS tracks who's working on what.

Ok - why not just make the file then?  I am sure that every active committer
will step up to do this.

The thing that we do get out of this is a formal accountability to the ASF -
but it strikes me as strange that we take all (or most) committers,  define
them to be the PMC, and all of a sudden accountability happens.  Do you see
what I mean? 
Seems like we have a problem if our committers aren't responsible and
willing to be held accountable.

> We can create some rules so that any committer can join the SPMC by
> volunteering for some components and participating in some sort
> of load distribution, and use this as a way to pass information.

What information?  Why not the usual list?  We wouldn't want this to be
closed, would we?

>>> The open questions are:
>>> - can jakarta PMC recognize jakarta-commons SPMC and delegate oversight
>>> officially ?
>> Good question, and I donĀ¹t see why we couldn't ask, although....
>>> - if that's not possible, can jakarta-commons form a PMC and ask the
>>> ASF board to recognize it ? ( it seems implied that tomcat or ant could
>>> do that easily ). If so, can it remain part of jakarta ( and eventually
>>> extend/merge with )
>> Yes, it could.  I would really be against J-C separating from jakarta in any
>> way.  Renaming all committers to be members of the PMC again seems like
>> window dressing until you educate those committers about their
>> responsibilities - where I then wonder if there is education to be done, why
>> don't we just do it?
> I'm not very sure what education - I suspect we all know the rules.
> We do need probably a bit more formal organization - and some
> explicit procedures/rules/plans.
> Regarding 'separating from jakarta' - I do think that j-c is in a way
> the 'core' of jakarta ( I don't know any other jakarta sub-project
> to bring so many people together ).

Bingo. +1.  Exactly.  That was the intent, and that is what we achieved.  To
break it up or move it  in the name of 'community' means someone is missing
the point (not you, Costin)

> But I wouldn't mind opening it up to people - we already
> have few great committers from xml working on j-c, and I think it would
> be great to expand this.

Fine - our hurdles for becoming a committer aren't very high.  Do we have a
problem where XML people aren't being allowed to contribute?  I mean, if
someone showed up with patches or new code, I think there is enough mixing
of the communities that the person would be granted committer status, just
like we automatically let in committers from other Jakarta projects, right?
>>> - technical details: who is part of the SPMC ( my initial proposal was
>>> 'all active committers who like to be', maybe with a 1-2 month delay for
>>> very new committers ). I'm sure other opinions will be raised on this.
>> This is why I think it's window dressing - why would you *not* allow a
>> committer to be participant in the PMC?  Would that reason, whatever it is,
>> be a reason for them not to be a committer?  Don't we believe that when we
>> make someone a committer, its because they have shown they share the vision
>> and are willing to take responsibilty?  It's more than just the ability to
>> 'cvs commit'.
> I think a 1-2 month delay is just reasonable - to let him get used with
> the environment and the rules. But I'm ok with dropping it ( again, this
> is my understanding of httpd procedures ).
> Using 'active' is a way to make sure we have things covered up and
> to track the people who are involved. If some European committer
> takes a 3-month vacation he should remove himself from the 'PMC' list
> and add back when he returns. This way we'll know that whatever
> he was monitoring/working on is not covered and we can redistribute it.

Yes, those damn Europeans with their 3 month vacations :)


> I see little value in a very large PMC where 1/2 of people don't
> track the mailing list.
> I'm also very strongly against any 'elective' system - as you said,
> if someone is voted as committer he should also be trusted ( after
> some adjustment and READMEs ) as PMC.
>> Just curious - I am asking the same questions about HTTPD and APD, as it
>> sounds like it's pretty much the same thing.  They assure me it's not, for
>> example the HTTPD PMC election is based on 'merit', where the Jakarta  PMC
>> is a 'popularity contest', but no one has yet to define the difference.
> AFAIK HTTPD PMC includes every committer.

I don't think so - I asked.  It doesn't include every committer, and those
that are a part of it are elected by the existing PMC based on 'merit'.

I haven't had time to ask for clarification.

> I think it's more of a naming issue - the jakarta PMC is mirroring the
> board ( i.e. small set of people, elected ). I don't think
> it's 'popularity', but more 'trust' that is the target of the election.
> Each jakarta subproject behave just like httpd or apr - with all
> active committers doing all the code reviews and monitoring and
> decisions.

Well - don't the active committers of each jakarta subproject *already* do
the code reviews and monitoring and decisions?  What else are they here for?

I somewhat resent the idea that Jakarta PMC is a popularity contest.  (And
not because I'm on it...)

Every person that I have voted for on the PMC is, in my opinion, someone who
understands Jakarta,  has a clear view supportive of Apache goals, has
contributed to one or more subprojects in a significant way, and is active
in the community.  What other definition of merit would one want?

> The problem is that we call things differently, and this de-facto
> 'delegation' that happened since the beginning of jakarta is now
> considered a problem.

I understand that there are legal issues that must be addressed, but I can't
believe that such a lively community, with both diversity and strength in
the ASF licensed code bases, could have happened as a series of one-offs
attaching to the ASF as 'top level projects'.

If there are problems, lets solve them.  Lets not destroy Jakarta in doing
>> To me, merit would be objective, popularity would be subjective.  However,
>> there are no objective measures of merit here, only opinions of those
>> voting. (HTTPD has the curious feature that only the existing PMC can vote
>> in new members, not the rest of the community... I have yet to ask about
>> that....)  My work in Velocity is really valuable to some people (like
>> myself :), but someone else, say someone working on Jasper, might not think
>> so and believe it is anti-Apache, for example, as one of it's benefits is to
>> 'undermine' a standard, JSP, through the offering of an alternative.
> Again - IMHO it's trust that is measured by the election.

That's probably a good way to describe it.
> And I think trust has nothing to do with what you work on or what
> technical opinions you have ( including 'hot' issues like JSP/Velocity).
> I think I had technical disagreements with almost everyone in jakarta.

And I don't think that JSP vs Velocity is a hot issue anymore.  The answer
is clear 


Geir Magnusson Jr.                                    +1-203-355-2219 (w)
Adeptra Inc.                                         +1-203-247-1713 (m)

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

View raw message