A short & sweet reply, dwelling largely on factual corrections if I may:
Avalon does have to chaff amongst the wheat. Some of it is mine, which we agree should be deleted or moved to incubator.
* Avalon-Framework is rock solid and should not be written as it is at version 4.1.3 (released).
* Avalon-Excalibur produces multiple products that are at different levels. Some are moving to commons, some will be firmed up in-situ, some will be deleted as they are no longer used. 1.0 is a common version number for the 10-15 prominent projects in there. A couple of comps are worthy of promotion to a jakarta front page level (Merlin and AltRMI ?) Some repackaging/rewrite may be needed here. The angle for Excalibur sub projects is that they are plain beans designed along a component model - as reusable as commons comps.
* Avalon-Logkit is at 1.1.1 level (released) and very solid. No rewrite needed here
* Avalon-Phoenix is at 4.0.2 (released) with 4.1 being worked on. This does not need a rewrite, especially as multiple companies are using it for internal projects.
* Avalon-Cornerstone is a set of comps for Phoenix. It is uses as much as Phoenix is but needs to be pushed forward to a release. There is a dependency on Phoenix or Phoenix-compatible projects (we voted recently that projects like Merlin should import the phoenix-client jar for compatibility with designed-for-phoenix comps).
* Avalon-Apps is a set of Phoenix applications. Some have been dead for a while and will be blasted out of CVS. Others like FtpServer (FtpLets?) are worthy of being made more prominent projects at Jakarta. These are mostly unreleased. We need to address that.
---
What characterizes Avalon and Avaloners is a belief in the Avalon-Framework lifecycle interfaces and the Inversion of Control pattern for component designs. We'd love to see these two push out further into other Jakarta projects. Particularly projects like Catalina :-) We do juggle multiple containers (Phoenix, ECM, Fortress, Merlin, Tweety). The Turbine team, with our full blessing, develop one of their own. I and others have one too that honors the lifecycle interfaces, but aims at a being a replacement for EJB called Enterprise Object Broker. Like most in this familiy it has its way of lacing comps together. These containers all favor the A-F lifecycle interfaces, but have different ways of lacing their components together and handling configuration. This is completely fine.
In summary, the need for wholescale rewrite / startover is not there. The need for chaff elimination and continued binary releases is there.
Regards,
- Paul
[ 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:
Yup, great, and shouldn't be necessary.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)
...In short, my request to the Jakarta PMC was "something needs to be done". Of
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.
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 ...The primary motivation is to create a more direct path from those
Now that the noise has settled down, there is discussion within a
bunch of Jakarta projects concerning escalation.
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
individuals.
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 :-)
...That is part of it, yes. My own opinion is also that the PMC did not manage
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.
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'sAgreed.
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 AvalonThe role of a PMC member does not incur any overhead relative to what you
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.
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
necssary.
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 [EMAIL PROTECTED]
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
Cheers,
-g
(*) 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.
-- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
