Greg Stein wrote:
[ setting mail-followup-to to avalon-dev; people on the PMC should watch the
  -dev list to truly track this conversation ]
[...]

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.
Avalon means many things to many people ;-) but actually there is one thing that has had many releases, is stable, and works very well: Avalon Framework.

This is where Avalon *really* shines, and where the community seems to actually be able to work together.

The fragmentation of Avalon is with the implementations of that framework, that are numerous and ever-evolving.

When I came in Avalon I really wanted to see us unite in a single design, and this brought me to try and move non-Avalon-dependent stuff to Jakarta Commons (with a good response), to help discuss things to unite implementations (Forrest and Merlin), and to seek to reunite all under a single implementation.

The fact that there are so many implementations is an indication of the state of flux in which implementation decisions are; I thought that with community discussion we could work things out on implementation; things worked for some but somehow started degenerating with others... my "famous" -1 that I retracted was an effort (albeit clumsy and uncorrect) to help sparkle discussion on a common solution, that the commit was somehow putting down.

I'd be more than glad to see it starting again.

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.
Let's start a new avalon repository with all the framework stuff.
Then add only things we vote positively on. One by one.

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.
We have already been suggested to reunite the repos, and it has gotten a non-negative reception.

I'm +1 to do it with the new Apache Avalon Project.

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".
+1

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.
+1

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.
+1

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 (**)
+1 from me :-)

assuming so:
2) craft a resolution; look at others in the Board minutes for an example
Who wants to take this up? Peter?

3) decide on the initial PMC and the Chair
I would like to be in the PMC, more because of my personal involvement in the Avalon Community than for my code commits, which are not much.
I have learned a lot about Avalon recently and think that I can give a positive contribution to Avalon by being on the PMC.

But I don't want to force it, and would like other committers to talk to each other about it privately or publicly and let me know.

Not being on the PMC will not diminish my interest or future commitment to Avalon in any way, nor my respect and collaboration with other committers, so feel free not to want me in for now.

If you want, I'm willing, if not, I'll help anyway :-)

As for the chair, let's see who's willing first ;-)

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.

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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

Reply via email to