[ 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 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 :-) >... > 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. Agreed. > 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 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. -- [EMAIL PROTECTED] ... 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>
