APACHE AVALON PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2003/06/21 12:25:58 $] Background: Apache Avalon is a project started at java.apache.org. It later became an Apache Jakarta subproject. It has recently been declared a new top-level project with its own PMC. See the bottom of this file for the official resolution/ charter-as-it-stands. See the project website for other information. Release: o We are in the midst of putting together a Release Plan for all Avalon technologies, codenamed ACR (Avalon Coordinated Release) o Phoenix released. o past releases available from http://www.apache.org/dyn/closer.cgi/avalon/ o nightlies available from http://cvs.apache.org/builds/avalon/nightly/ Resolved Issues: o previously released software needs to be supported, including but not limited to the avalon framework, avalon excalibur and avalon phoenix o existing avalon users must be supported, including but not limited to the XML Cocoon and Jakarta JAMES communities o we want to strive for as much consensus on future developments as possible taking into account the above points o There is an Avalon repository called avalon-sandbox to contain all non-released code. It has its own site to make less confusion with released products. o Use a unified avalon-dev mailing list (and avalon-user remains separate) o To mark sandbox code clearly as being sandbox code, we do not require that components in this place are put in the package org.apache.avalon.sandbox.X; they will use the same package names they will use if/when they are graduated in main CVS. o Context contract has been updated to reflect current usage. [http://marc.theaimsgroup.com/?t=103986366100001&r=1&w=2] o Every committer that will propose an internal fork will have to go thru the community vote to be allowed to do that. [http://marc.theaimsgroup.com/?l=avalon-dev&m=103903695931512&w=2] [http://marc.theaimsgroup.com/?t=103904717500001&r=1&w=2] [http://marc.theaimsgroup.com/?t=103908800800002&r=1&w=2] o All @author tags and all reference to authors of source code files will be also kept in the files themselves. o Avalon PMC Voting Procedures accepted 2003-01-31 Proposal: [http://marc.theaimsgroup.com/?l=avalon-dev&m=104339946013500&w=2] Result: [http://marc.theaimsgroup.com/?l=avalon-dev&m=104400855421800&w=2] o The STATUS file is a great means of synching the community agenda. For each [Proposal] and [Vote] and release there be an entry in the STATUS file, that has to be updated by the original item proposal. Proposals should be entered as such, votes should have listed all current votes and the vote start date, and when the issue item is completed, the names of the voters are removed and it's resolved, positive or negative. Releases too should be listed. *NOTE* Votes and all action items that are placed in the STATUS file are valid if done by their rules. In other words, the STATUS file does not validate them in any way, it's just a community synch tool. If something doesn't go into the status file, it still exists and is perfectly valid. o Avalon PMC Voting Procedures updated 2003-06-21 Proposal: [http://marc.theaimsgroup.com/?l=avalon-dev&m=105559070910800&w=2] Result: [http://marc.theaimsgroup.com/?l=avalon-dev&m=105619731625094&w=2] Pending issues: o nicolaken: Deprecation policy Removing deprecated classes between major versions is a safe bet. Between point versions it's a possibility. Between fixes it's an error. I'd suggest the following as a guideline: - deprecating classes results in @deprecated being added - in the next minor point release, they are moved to a deprecated source tree for the component that is compiled *after* the main ones, so that we are sure that /we/ do not rely on those. - in the major releases the classes can be removed with a vote. o nicolaken: Previously, I had asked that the maven descriptor in the avalon CVS not be in the main dir, not to confuse our users. But it's also possible that we just don't include it in the releases. Given that there is much discussion on things that developers don't even know what is about, I think it's in the best interest of all Avalon that build tools alternative to Ant are included in the correct places in our projects so that all developers can evaluate them and decide on merit rather than feeling. This of course also means that we accept the POMs from Jason, and can commit any other build system too for comparative evaluation. What do you guys think, is this reasonable? o [VOTE] Do you want that we discuntinue Excalibur CLI in favor of Jakarta Commons CLI? +1: nicolaken, mcconnell +0: -0: -1: o Coming up with a set of bylaws for the project o Define the terms for serving as a Chair Note: this is actually defined by the bylaws and board resolutions, and we have no role in defining this. o Roadmap Avalon will be focussing container development into two efforts. The first one is the creation of Avalon ESCA. To this end, most existing avalon container projects will refocus to be part of that goal. The roadmap for this effort is roughly as follows: - Milestone 1: ECM replacement (Codename: Fortress) - Milestone 2: Proper Meta Model (Codename: Merlin3) - Milestone 3: Phoenix Compatible (Codename: Phoenix5) - Milestone 4: Profileable, pluggable container (Codename: Spearhead) The second container development effort is the maintainance of existing released efforts with an existing userbase, ie phoenix. This will merge into the ESCA effort when there is an ESCA release compatible with those existing efforts. ==================================================================== ECM --> Fortress --> Merlin3 --> Phoenix5 --> Spearhead --> ... ^ ^ ^ | : | Merlin1&2 (unreleased)-| : | All other | :(synergy) | container dev code -/ : | : | Phoenix4 -------------------------------/ ==================================================================== o discussing and writing short-to-medium term roadmap regarding unused and/or unmaintained and/or alpha-stage software packages in current CVSes o discussing and writing short-to-medium term roadmap regarding possible relocation of software packages that could have a better home at another avalon project o wrap up discussion on licensing headers in sourcefiles o Existing committers can start new projects without a detour to the Incubator by using the avalon-sandbox, and must meet the (TBD) goals of Apache Avalon. These new components must be approved by the PMC before being accepted in the endorsed repositories, and must meet the (TBD) goals of Apache Avalon. +1: nicolaken o Voting will follow the "standard Apache voting guidelines" [ be nice to refer to an Incubator doc here ] o All code donations [to the ASF, destined for Apache Avalon] arrive via the Incubator, unless the Incubator states they can be placed directly into Avalon. -1: leosimons - I think that if, for example, our company wants to donate avalon-related code to avalon, the best body to judge whether the donation should be accepted is avalon. If it's about "code-with-a-community", like EOB maybe if it comes this way, it's a different story. o Come up with a Meta-Info model for Context. o Define standard Context entries. o Last-minute changes to the Context javadocs. o fix the build system (for excalibur) (so that gump gives green light again). Do we move to maven? Wait for a 1.0 release perhaps? o move over docs to forrest (currently there's a branch in the avalon module which we need to merge back and move to, but there's some stuff left to do). Project Mission: Note: work is underway in avalon/src/proposal to define a charter, including mission. What is the project's mission? Our statement of goals/mission/vision could arise also from the answers to the following and other questions: - Should we have a minimum set of requirements before components are released? - If yes to above then which things should be part of minimum requirements? documentation: require basic overview and user docs uptodate website: require website be updated to latest release but may still host previous release docs. unit tests: (okay so this will never get consensus but ...) versioning standard: derived from http://apr.apache.org/versioning.html http://jakarta.apache.org/commons/versioning.html release process: derived from http://jakarta.apache.org/commons/releases.html http://jakarta.apache.org/turbine/maven/development/release-process.html http://cvs.apache.org/viewcvs.cgi/ant/ReleaseInstructions?rev=1.9.2.1&content-type=text/vnd.viewcvs-markup deprecation process: (java specific?) http://jakarta.apache.org/turbine/maven/development/deprecation.html CVS/Subversion branching: http://jakarta.apache.org/turbine/maven/development/branches.html Assets: Mailing lists: users@avalon.apache.org dev@avalon.apache.org cvs@avalon.apache.org Web site: http://avalon.apache.org/ Repositories: avalon (framework) avalon-logkit (logkit) avalon-phoenix (phoenix) avalon-cornerstone (components) avalon-apps (sample phoenix applications) avalon-excalibur (everything else) avalon-sandbox (sandbox) avalon-site (the web site) PMC Members: Berin Loritsch Marcus Crafter Carsten Ziegeler Jeff Turner Leo Sutic Leo Simons Stephen McConnell Nicola Ken Barozzi Paul Hammant Peter Royal Note: Nicola Ken Barozzi is the Chair. PMC Members, pending Board approval: none yet [ this may become obsolete; the Board is discussing a way for the Chair to directly alter the PMC membership; until then, however, we need PMC members ratified by the board, and this tracks them ] Active Committers: bloritsch,colus,crafterm,cziegeler,hammant,jefft,leif,leosimons,leosutic, mirceatoma,mcconnell,nicolaken,proyal,vinayc,rana_b Inactive Committers (three months without commits): charlesb,ramc,neeme,giacomo,froehlich,jrudd,morpheus, crafterm,huw,ymikulski,mschier,stefano,lmccay Emeritus Committers (six months without commits): jon,fede Invited Committers: none yet Current mission/charter as approved by the board: RESOLVED, that the initial Avalon PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Avalon Project; and be it further RESOLVED, that the initial Avalon PMC be and hereby is tasked with the migration and rationalization of the Jakarta PMC Avalon subproject; and be it further The complete text of the resolution that passed on Monday 18 November 2002 which created this project is: WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to component and service management, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Avalon PMC", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Avalon PMC be and hereby is responsible for the creation and maintenance of software related to component and service management, based on software licensed to the Foundation; and be it further RESOLVED, that the office of "Vice President, Avalon" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Avalon PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Avalon PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Avalon PMC: * Nicola Ken Barozzi * Stephen McConnell * Leo Sutic * Leo Simons * Paul Hammant * Marcus Crafter * Carsten Ziegeler * Pete Royal * Berin Loritsch * Jeff Turner NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nicola Ken Barozzi be and hereby is appointed to the office of Vice President, Avalon, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Avalon PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Avalon Project; and be it further RESOLVED, that the initial Avalon PMC be and hereby is tasked with the migration and rationalization of the Jakarta PMC Avalon subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Avalon sub-project and encumbered upon the Jakarta PMC are hereafter discharged. # # Local Variables: # mode: indented-text # tab-width: 4 # indent-tabs-mode: nil # tab-stop-list: (4 6 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80) # End: #