In June of 2004, I worked with a bunch of other open source java developers to set up Apache Excalibur from some assets of the slowly disintegrating Apache Avalon. It was my first time setting up a top-level project at apache and I learned a lot from that experience which I applied as a mentor at the Apache Incubator for a couple of years.
Welcome, community
I sent an e-mail:
Hi gang! It all took a bit (way!) longer than expected, but bits and pieces of our infrastructure are finally dropping in place. It'll be a while before we've got everything running (in particular svn not working yet; unix group contains just me; etc etc), but we now have a place to talk! What I don't want to do yet is send out all these big announcements just yet. Announcements are more sexy when they're not just "new project with old code will Kick Ass(tm)". We're all exited, but there's no particular reason for anyone else to be. Yet. What I would like to do is get some idea of where you all want to go. Who are you, where do you want to be tomorrow, and how does excalibur fit in? cheers, - Leo
Welcome, PMC
And more e-mail:
Hi gang! (This e-mail is primarily directed at the Excalibur PMC members, but intentionally on a public mailing list because everything that doesn't need to be secret will not be.) Some of you have lots of experience around the ASF, others are shiny new committers who still lack a unix account. This e-mail is to give you a basic idea of what it means to be "on a PMC". "Core group" ------------ First of, "Project Management Committee" is a ***bad*** name that has stuck for historical reasons. The daily "management" of this project is done by its committers, and the not-so-daily matters are often done in co-operation with other teams at apache, like the board and the Incubator. A much better name for "PMC" is "core group". Shame we're kinda stuck with "PMC". O well. We, the PMC, are, together, responsible for the success of the excalibur project. As such, we are tasked with "creation and maintenance of embeddable software libraries related to component and service management" all this based on, and in alignment with, the basic goals and principles of the ASF. While most apache projects have a tendency to drift somewhat from that designated task (for example, we have xmlutil under our wings, which is hardly about service management), the part about "in alignment with the basic goals and principles of the ASF" is something not to be drifting away from. Being responsible is not the same as doing things. If all is well, the PMC doesn't do a whole lot at all. The people who do the work are the committers and contributors. Committers ~= PMC? ------------------ Most committers are also pmc members. This is on purpose. It makes us "self-managing": the people doing the work are the people in charge. Some committers are not pmc members. If all is well, that is a temporary situation, where someone has just been elected as a committer but still has some things to learn before stepping on the PMC. In other cases, a committer may not have the desire or ability to take on the responsibility that comes with being on a PMC. Just like contributors can get invited to become a committer, committers can get invited to become a pmc member. pmc@excalibur.apache.org ------------------------ The PMC has a private mailing list to discuss sensitive issues. If all is well, there are no sensitive issues, and there are just about 0 messages exchanged on that list at all. Note that the pmc list is not actually restricted to just the PMC: board members and ASF members may hang out there as well (and often do), to offer useful advice. All non-sensitive issues that the PMC deals with are not dealt with on the PMC list, but on this one. This message is one example. Some things that are dealt with in public include discussion about project progress and policy, votes on project releases, etc. Things that are dealt with privately include code security problems, some legal stuff, and discussions and votes about people (like election of new committers, pmc members, and the pmc chair). Even people who are not on the PMC, can (and do) still send e-mail to the pmc list if there's a sensitive issue related to excalibur they wish to discuss. Learning the ropes ------------------ There's a lot to learn about the way the ASF works; I've been learning my way around for a few years and I still get lost sometimes. Take a look at Stefano's whitepaper someday: in the meantime, just remember to tread lightly if you're unsure where you're going, and to ask lots of questions... Cool! ----- Being on the Excalibur PMC is a cool thing! You're taking on real responsibility for a big project at The Apache Software Foundation. You're part of the "people in charge" now. This means, among other things, that the ASF thinks you capable of project management (and trusts you to not act like you're in charge at all!). Don't dissapoint em 😀 cheers, - LSD
Procedures and policies
And even more e-mail:
Hi gang! We do need /some/ procedures and policies I'm afraid. For example, the PMC must endorse (by voting) all project releases. Coding standards are another one of those. I don't feel very much like re-inventing the wheel or spending much time on all of this. I propose that we incorporate the procedures followed by avalon, by reference, in particular, that's http://avalon.apache.org/community/process/pmc-votes.html http://avalon.apache.org/community/process/code-standards.html http://wiki.apache.org/avalon/AvalonMailingListEttiquette http://wiki.apache.org/avalon/AvalonDistributionLayout http://wiki.apache.org/avalon/AvalonReleaseManagerHowto to the maximum extent possible (ie the actual distribution layout is of course different). We can change things as they itch. Where bits of procedure and policy are not specified by avalon docs, refer to the process as written down on the jakarta site: http://jakarta.apache.org/site/getinvolved.html those of you who've been active on the avalon pmc should have no problems applying all of this. Those of you who are new to the role, you really don't need to go and read all of that right now. Just go with the flow and ask questions. The basic summary is as follows: * don't smack each other on the head (or not too hard), behave like a responsible adult, use common sense, etc * +1/+/-0/-1 mean what you expect of 'em * releases are a big deal and need to be voted on * ASF is strict about licensing/IP/etc stuff and there's rules to follow and people to speak to (like the apache incubator) * a -1 is a veto unless specified otherwise or the vote is among the PMC (the PMC doesn't have vetoes) * vetoes suck and arise from a failure to communicate * by ASF bylaws, the PMC chair (currently that's me) is always right, if he/she wants to be, and can overrule or simply ignore any decision made by the committers or pmc * basically more common sense stuff I also recommend people who go and read the above docs to also take a look at the codehaus manifesto, which is brief and blunt: http://www.codehaus.org/Manifesto not that it applies here (this is not the codehaus after all), but it does provide some contrast with the "ASF process" as hammered down in all the policy documentation. Finally, everyone who's an asf committer, esp. pmc members, needs to be familiar with the ASF bylaws: http://www.apache.org/foundation/bylaws.html this is a binding legal document (unlike all the other stuff referenced above). We shall adhere to it. comments? cheers, - Leo
Archiving
I like to look at my archives to see how my style has changed over the years. It’s nice to see the Apache mail archives for excalibur are still complete, online, and searchable.
About a year ago I converted the old Avalon and Excalibur source code from SVN to Git and archived it on github:
LSD::RELOAD 