Federico Barbieri wrote:
Stephen McConnell wrote:
Ths process has been initiated based on the the discussion here under the thread "Thoughts on an Avalon PMC".
I've been through (most) of it in the last days. I know many people are supporting this move and I'm happy about it. That is not the point.
I'm trying to clarify (to myself at least) the legal process involved.
I don't know if there is a choice between A and B. That was my only concern. Do you have details on this?
Lets' assume for the moment that I may have a disagreement concerning the question.
:-)
Given the active engagement of lots of people both within and up the chain of responsibility, I thihk you will find that the process is completely in line with the Apache process for PMC formation. This is not to say that the work is done - because there is still much to do on the area of reorganization and my guess is that this isn't something we will agree on overnight. It will be much more a case of open deliberation and constructive attempts at the developoment of concensus on the subject. In parrallel, there are already activities in place to facilitiate the migration of some of the content of Avalon - in particular, some of the components in Excalibur are likely to kmore rapisdly to Commons and some of the applications in the Avalon Apps area already well into processes that would facilitate igration out of the Avalon.
I don't understand your disagreement... It could just be I'm digital and you're analog thou... :)
Actually, I'm biologic. :-)
My suggestion is to start discussing what should or should not be under the Avalon PMC, when and how. The sooner you decide this the better.
Agreed.
This is something explicity addressed within the resolution through the requirement for the PMC to handle restructuring. But before getting into the actual restructing process, lets look briefely at the implications that restructuring has on Avalon and the user base.
I think there is general concensus that stuff will be moving out of Avalon - for example, component in Excalibur that are more appropriate in Commons, potential establishment of new projects (or sub-project) as a result of assement and migration of content in Avalon Apps. Initally I think we will see "active migration" in which sub-sub-projects take the iniative and get themselves organized. This "active migration" process is already to some extent initated - for example there is already work going on with the board in telation to the enterprise suite of compents which has a direct bearing on license, ownerships aspects, and an external development community. In the context, active-migration means more that saying X is in and Y is out - its much more about enabling constructive and positive migration. The easy step is probably the generic non-Avalon specific resources in Excalibur. Escalating up from that we have components over in Avalon Apps - many of which are tied to Phoenix. While practically all of these Phoenix associations can be elimiated, there are at least to community issues that this brings up.
* Avalon Apps was initiated as a repository for Phoenix components
* Avalon Apps is not part of the Phoenix CVS
* Phoenix dependencies where present are at best questionable
* There are components in Avalon Apps that are Phoenix independent
* There has been at least one suggestion that Phoenix should be
seperated from Avalon
* There are external communities that are using these components
in the context of Phoenix and other containers such as Merlin
Resolving all of this requires lots of discussion because there are lots of underlying issues here. Onoe of these is comming to agreement on container independence is scenarios where container depedence is nothing more that a convinience factor.
In the above cases I can solutions emerging from a healthy debate, and if necessary, the intervention of a knowlegeable PMC to resolve issues that the community cannot reach for whatever reason (e.g. fragmentation of the community across different areas).
Beyond all of the list, their remains the LogKit application and its relevance to Avalon. One can view this something totally orthoginal to the Avalon objectives, and at the same time, we can argume that the design patterms in LogKit somehow make it aprt of the Avalon scope. Personally I would prefer to see LogKit head in the direction of Florida - but before that I know I have work to do in migrating to alternatives. I.e. this is not an overnight scenario, instead, we are talikng about a managed and well suppprted trasnition across a bunch of application areas.
fede
Hope that helps.
Cheers, Steve.
p.s. Where have you been lately - havn't seen you around on Avalon for a long time?
and I'm still curiouse .. Cheers, Steve.
SJMfedeCheers, Steve.
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.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>
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
