Differences between revisions 68 and 69
Revision 68 as of 2004-05-10 06:09:54
Size: 8547
Editor: giraffe
Comment: voting period over.
Revision 69 as of 2004-06-27 15:12:08
Size: 379
Editor: giraffe
Comment: this page is no longer neccessary
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Avalon Project Reorganization = == Reorganization complete ==
Line 3: Line 3:
There is a great deal of tension and contention within the Avalon project. The primary areas of disagreement surround container development and support of existing containers and their users. In response to this, the Avalon Community is attempting to re-organize. This page is an attempt to provide a jointly editable consensus with which to approach the ASF Board.

Please help edit this page to reflect a consensus that you can accept, and express your interest in participating.

== New Projects ==

There would be a Federation of Avalon-originated projects, broken down into roughly the following groups:

 1. Avalon
  1. Purpose
      ''Creation and maintenance of specifications, software and component infrastructure related to component and service management interoperability.''
  1. Contents
   1. Avalon Compatibility Specifications/TCK
   1. Avalon Frameworks
   1. Avalon Components
   1. Avalon Site
   1. Avalon Sandbox
  1. Federated Projects
    ''The Federated Projects are those that build container solutions based upon the Avalon compatibility and interoperability specifications.''
   1. Merlin
   1. Fortress
   1. Loom
   1. ''Other Federated projects might be accepted in the future, if there is sufficient community support and they support the commonly agreed upon TCK.''
  1. Commit Access
   1. Access to Avalon Frameworks and Site granted to Committers on all federated projects.
   1. Access to Avalon Components granted to Committers on federated and using projects.
  1. Preliminary composition of the Avalon PMC
    ''The proposal is to have two representatives from each federated project, one representative from each ASF ''using'' project, and the Chair of the PMC appointed by the Board. Niclas also suggest that each represented project establish procedure for selecting the representatives for the Avalon PMC as soon as this proposal has been set in motion.''
   1. J Aaron Farr (current Chair)
   1. Merlin
    1. Timothy Bennett
    1. Niclas Hedhman
   1. Fortress/ECM
    1. Berin Loritsch
    1. Leif Mortenson
   1. Loom
    1. Peter Royal
    1. Mauro Talevi
   1. ASF User Projects
    1. Noel J. Bergman - James
    1. Alex Karasulu - Directory/Eve
    1. Carsten Ziegeler - Cocoon
  1. Committers - Framework
   1. Timothy Bennett
   1. Noel J. Bergman
   1. Shash Chatterjee
   1. Peter Donald
   1. J Aaron Farr
   1. Niclas Hedhman
   1. Alex Karasulu
   1. Berin Loritsch
   1. Stephen Mc''''''Connell
   1. Leif Mortenson
   1. Michael Nash
   1. Andreas Oberhack
   1. Neeme Praks
   1. Peter Royal
   1. Leo Simons
   1. Mauro Talevi
   1. Hamilton Verissimo de Oliveira
   1. Carsten Ziegeler
  1. Committers - Components, Site & Sandbox
   1. All of the above
   1. Existing Cocoon committers
   1. James committers
   1. Directory/Eve committers
 1. Merlin
  1. Purpose
     ''creation and maintenance of a platform for Advanced IOC Global Component and Service Management''
  1. Description

     [http://www.apache.org/~mcconnell/merlin/pub MerlinTLPOverview]
     [http://www.apache.org/~mcconnell/merlin/pub/docs/history.txt MerlinHistory]
     [http://www.apache.org/~mcconnell/merlin/pub/docs/description.txt MerlinTLPDescription]

  1. Consensus among the Merlin committers.
   1. A Merlin TLP should be created, and that process should start as soon as possible.
   1. The initial PMC is listed below.
   1. The ''new'' Avalon composition is in the best interest of ALL users and projects built on top of the current Avalon Framework 4, effectively protecting each groups vested interest in AF4.
   1. The ''new'' Avalon is a collaboration platform to discuss improvements in interoperability and not a battleground for compulsory specification compliance.
  1. Contents
   1. Merlin Logging
   1. Merlin Util
   1. Merlin Core (Composition, Activation, Kernel, Tutorials)
   1. Merlin Facilities
   1. Merlin Developer (Eclipse Plugin)
   1. Merlin Repository -> (Long-term) Depot based implementation
   1. Merlin Meta
   1. Merlin Site
  1. Commit Access
   1. Access to Merlin is granted to all Merlin Committers.
   1. Access to Repository possibly to the Depot people to help with Refactoring
  1. Initial PMC
   1. Timothy Bennett
   1. J Aaron Farr
   1. Niclas Hedhman
   1. Alex Karasulu
   1. Stephen Mc''''''Connell
   1. Andreas Oberhack
  1. People interested in being a Committer
   1. Timothy Bennett
   1. J Aaron Farr
   1. Niclas Hedhman
   1. Alex Karasulu
   1. Stephen Mc''''''Connell
   1. Andreas Oberhack
 1. Fortress/ECM
  1. Purpose:
      ''Creation and maintenance of embeddable software libraries related to component and service management.''
  1. Contents
   1. Fortress
   1. Excalibur
   1. Excalibur Component Manager
   1. Fortress Meta
   1. Fortress Site
  1. Commit Access
   1. Access to granted to Fortress/ECM Committers.
  1. People interested in being on the PMC
   1. Shash Chatterjee
   1. Peter Donald
   1. Alex Karasulu
   1. Berin Loritsch
   1. Michael Nash
   1. Leo Simons (proposed chair)
   1. Hamilton Verissimo de Oliveira
   1. Carsten Ziegeler
   1. J Aaron Farr
  1. People interested in being a Committer
   1. Shash Chatterjee
   1. Peter Donald
   1. J Aaron Farr
   1. Alex Karasulu
   1. Berin Loritsch
   1. Leif Mortenson
   1. Michael Nash
   1. Neeme Praks
   1. Peter Royal
   1. Leo Simons
   1. Mauro Talevi
   1. Hamilton Verissimo de Oliveira
   1. Carsten Ziegeler
   1. Anton Tagunov

== Pending issues ==

== Unresolved Issues ==

== Resolved Issues ==
=== Avalon Logging ===
 Avalon Logging (avalon/logging) has previously been touted as a replacement of the older excalibur-logger, and is fairly flexible and powerful. However, currently Avalon Logging depends on Repository (avalon/repository) for Jar management and classloader establishment, and that dependency is possibly not in the interest of the Fortress project, whereas the more generic parts of Avalon Logging may be of greater interest. The Merlin committers are suggesting that the Avalon Logging is initially moved to Merlin, where the Merlin committers will try to remove the Repository dependency and submit back to Avalon a more generic solution.
  1. Fortress has to focus on limiting its dependency list rather than expanding it. A light footprint is important.
  1. Any reason why a simple Logger.getChildLogger() can't be done?
  1. We can also move to a Monitor design, suggested by Paul Hammant
  1. Repository is a completely separate concern from logging, if "Avalon Logging" cannot be used without the repository, then it fails in its mission. Put shortly, the repository '''can''' be used if present, but should '''not be required''' to be used.

'''''Resolution:''''' Avalon Logging is moved to the Merlin TLP, and the Merlin group will invesigate the 'generalization' of the codebase.

=== AvalonNet / Castle ===
 Castle/Avalon''''''Net is an ''dotNet''/Csharp container implementation of the AF4. There are several options.
  1. It stays for the time being in the Avalon Sandbox.
  1. It is moved to Incubation.
  1. It is moved to Fortress TLP.

=== Mission statement ===

 1. Is the above mission statement for Fortress/ECM OK? Place your votes here...voting open till roughly may 10, consensus required...
  Resolution: '''''yes'''''
   1. Shash Chatterjee
   1. +0 Peter Donald
   1. +1 J Aaron Farr
   1. Alex Karasulu
   1. +1 Berin Loritsch
   1. Leif Mortenson
   1. +1 Michael Nash
   1. +1 Neeme Praks
   1. +1 Peter Royal
   1. +1 Leo Simons
   1. +1 Mauro Talevi
   1. +1 Hamilton Verissimo de Oliveira
   1. +1 Carsten Ziegeler

=== TLP name ===

 1. Should it be fortress.apache.org or excalibur.apache.org?
  Resolution: '''''excalibur.apache.org'''''
  * Excalibur
   1. +1 J Aaron Farr
   1. +1 Michael Nash
   1. +1 Neeme Praks
   1. +1 Leo Simons
   1. +1 Mauro Talevi
   1. +1 Carsten Ziegeler
  * Fortress
   1. +1 Peter Donald
   1. +1 Alex Karasulu
   1. +1 Hamilton Verissimo de Oliveira
  ''Note: quite a few people don't care much about the name''


'''''Resolution:''''' AvalonNet remains in the Avalon-Sandbox by now.

== Resolution Drafts ==

 * [http://www.apache.org/~mcconnell/merlin/pub/docs/resolution.txt MerlinTLPDraftResolution]
 * [http://wiki.apache.org/avalon/Reorganization_2fDraftBoardResolutions FortressTLPDraftResolution]
Merlin stays at avalon, as do cornerstone and Avalon Castle and mostly everything else. Excalibur has become a top level project. If you wish to see what all this was about, go retrieve an older version from http://wiki.apache.org/avalon/Reorganization?action=info. Make sure to read the mailing list archives for the needed additional context.

Reorganization complete

Merlin stays at avalon, as do cornerstone and Avalon Castle and mostly everything else. Excalibur has become a top level project. If you wish to see what all this was about, go retrieve an older version from http://wiki.apache.org/avalon/Reorganization?action=info. Make sure to read the mailing list archives for the needed additional context.

Reorganization (last edited 2009-09-20 23:16:36 by localhost)