avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Avalon PMC] was Avalon PMC
Date Thu, 14 Nov 2002 19:51:17 GMT

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. 


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.

>> SJM
>>> fede
>>>>> Cheers, 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

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message