avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@apache.org>
Subject Re: thoughts on Avalon PMC
Date Sat, 09 Nov 2002 06:19:20 GMT
[ setting mail-followup-to to avalon-dev; people on the PMC should watch the
  -dev list to truly track this conversation ]

On Sat, Nov 09, 2002 at 04:07:38AM +0100, Stephen McConnell wrote:
>>> Leo Simons wrote:
>>> > It's all rather icky.
>>> >
>>> > options to make it less icky:
>>> > - jakarta PMC votes on releases (not really a practical option)
>>> > - avalon gets a board-installed PMC which votes on releases
>>> > - destroy avalon (rather not)

Yup, great, and shouldn't be necessary.

> Leo and Leo and everyone else:
> Earlier today some interesting emails have been crossing the Incubator
> and Jakarta PMCs in which the Avalon project is part of the subject
> material.

In short, my request to the Jakarta PMC was "something needs to be done". Of
the PMC people who responded, the general tendency seemed to be supportive
of creating an Avalon PMC, provided the community was amenable to doing so.
IOW, the PMC deferred first-rights to the community to take some action.

This means the community needs to reach a consensus on what to do. If that
can't happen, then the Jakarta PMC or the Board will Do Something(tm) :-)

>... snip good stuff about reorg@, accountability, etc ...
> Now that the noise has settled down, there is discussion within a
> bunch of Jakarta projects concerning escalation.

The primary motivation is to create a more direct path from those
accountable and responsible (the PMC) and the code. Without a direct,
obvious, and demonstrable oversight, it will be impossible for the ASF to
show that the code was developed and released according to *its* desires.
IOW, it was done by individuals, so the liability falls to those

Yes, the risk associated with that liability is awfully low, but the ASF
exists to make it zero. (the ASF exists for other reasons, of course, but
I'm trying to stay focused here :-)

> One of these problems has been identified as Avalon due primarily to a
> lack of oversight by a PMC member.  Without oversight it clear can
> the members of the Jakarta PMC cannot reasonably represent this
> commmunity towards the board.

That is part of it, yes. My own opinion is also that the PMC did not manage
the community properly. From my point, I see a highly contentious and
divided community. From some correspondence with Peter, it even sounds like
"each person is working on their own stuff" -- a bunch of personal
playgrounds, only loosely falling under some concept called "Avalon". This
is where that other part of the ASF comes in: providing rules, patterns, and
a framework for communites to exist, evolve, and (at the direction of the
PMC) to produce kickass code. Avalon has been described as being in
"perenial alpha", which isn't surprising considering its divided nature.

> Sam Ruby posted a message earlier today (copied with Sam's
> permission):
>  > My opinion is that Avalon with its various sub-subprojects,
>  > including excalibur with its sub-sub-subprojects requires a
>  > dedicated PMC for oversight.


> Greg Stein posted a follow-up in which he recommeded a new Avalon
> PMC chartered to rain-in everything in, sort it out, and basically
> start from scratch.  Greg also committed to posting his thoughts
> on an Avalon PMC directly to this list.

The role of a PMC member does not incur any overhead relative to what you
are already doing. In fact, Roy Fielding has stated that the division
between a voting committer(*) and a PMC member is not supposed to exist.
IOW, if you have voting rights, then you should be on the PMC.

The Chair has a duty to provide the Board with a quarterly report, but has
no other additional time overhead. The Chair *is* an officer of the
corporation, which incurs certain responsibilities and accountability, but
an officer also happens to receive more legal protection than the PMC
members :-)

In the Ant group, I've been somewhat disappointed to see most people
avoiding stepping up to be the Chair (thankfully, Conor threw his hat in the
ring). I'd like to avoid that here by explaining that it isn't a scary
thing... In fact, I would hope that everybody would be all right with acting
as the Chair.

So that wraps up the structural stuff: establish a PMC from the active
Avalon people. Pretty straight forward. Then what?

I think it was Costin that said it best: vetoes shouldn't be used to steer
the design. This is why I suggested (as Steve mentioned above) that the
Avalon project start over. As a community, decide what the heck Avalon is
and get it assembled. Either from old parts, or newly developed parts. But
ignore the design from the past and come up with an "Avalon 2".

I had even suggsted using org.apache.avalon2, although Sam pointed out that
would pose backwards compat issues. It sure would :-). But if Avalon hasn't
had a release, then it seems "okay" to just archive the old avalon and start
a new one, under a new namespace. JAMES and other users can migrate.

But hey... I know nothing about the ramifications of that :-). The question
for the new PMC to answer is: how do we start over to create a design that
is community driven? Another answer might be to break down Avalon into a
list of component areas and put them individually through a vote. "is this
good? bad? design okay? etc" Anything that is controversial gets ripped
until a consensus is formed.

Avalon is awfully big. Part of the review could be archiving pieces that no
longer "fit" or are unmaintained or whatever.

I might also suggest putting everything back into a single CVS, available to
all committers. I'm not sure why multiple CVS repositories exist (there
could be great reasons!), but one big CVS might help to create that "single
community" concept. Not sure, but the PMC may want to think about it.

I would also recommend that the PMC disallow forks or "revolutions." Get the
community to work together, rather than individually. If somebody is peeved
enough at the community's direction, they can put their fork in other parts
of the ASF or outside the ASF. But don't allow internal forks until you've
at least got one release behind you. This notion of personal playgrounds and
forks and whatnot has been part of the "avalon problem".

As a comparison point, the httpd group has recently decided to create stable
vs development branches. This "fork" of the code was done on a consensus
basis rather than individuals going off to work on their stuff. There *have*
been individual forks (apache-nspr being one, and apache-2.0 started off as
one), but httpd already had a stable release that had a community to gather
around it.

Well, I've rambled enough. As a Director of the ASF, I'd vote "yes" on an
Avalon PMC resolution. I would want to see *all* active committers on that
PMC, without exclusion. I'd want to see that PMC tasked with building and
releasing Avalon (according to some definition that you guys come up with
here). Once the Board establishes the PMC, then I'd hope its first task is
to take Avalon down to its core and rebuild it, with the whole community in
mind. As the Chairman, I'll be asking the PMC Chair for a report for the
first few months while the new PMC and project gets restarted, then it would
move back to quarterly.

The Board is meeting on November 18th after the Members meeting. It would be
best to have any resolutions sent to board@ by Thursday the 14th to give the
Board members ample time to review it and to suggest any changes, if

Direct action items that I would suggest:

1) decide if creation of an Avalon PMC is agreeable (**)

assuming so:
2) craft a resolution; look at others in the Board minutes for an example
3) decide on the initial PMC and the Chair
4) send the resolution to board@apache.org

Note that you don't have to have a detailed charter / rules / etc before
submitting this to the Board. The Board resolution sets up the PMC and tells
it "go make it happen", and part of *that* is to do the charter stuff.

I'm not subscribed to avalon-dev@ cuz there is a lot of other traffic here
that I just don't care to see :-), but I'm quite all right with being CC'd,
and I'll watch the list via gmane and/or marc.theaimsgroup.com


(*) I say "voting committer" because it is possible that somebody was given
commit access simply to apply some patches themselves, but they do not have
input into the direction of the project

(**) don't worry about "not being part of Jakarta"; Avalon can certainly
still have links from jakarta.apache.org; in fact, its web pages could stay
there, or move to avalon.apache.org; however you want -- top-level projects
get to have a hostname like FOO.apache.org, but it isn't required.

gstein@apache.org ... ASF Chairman ... http://www.apache.org/

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message