Greg Stein wrote:
[ setting mail-followup-to to avalon-dev; people on the PMC should watch the -dev list to truly track this conversation ]
[...]
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.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.
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.
We have already been suggested to reunite the repos, and it has gotten a non-negative reception.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'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?
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.3) decide on the initial PMC and the Chair
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>