Re: [PROPOSAL] Avalon Components

Nicola Ken Barozzi wrote:

>
> I propose that the Avalon Project creates a subproject called "Avalon
> Components", where non-core Avalon committers can work on Avalon
> components.


It's something that has been on my nind for several weeks.

>
> It would work conceptually like Jakarta Commons, and have its sandbox 
> open to all *Apache* committers. On the Avalon Components "proper", 
> the commit rights would be:
>  - all Avalon committers
>  - all committers that have been voted in by
>     Avalon+Avalon Component committers
>
> When one is a committer on Avalon Components, he can commit on any 
> part of the repository, not just the components that originally 
> interested him.


This sound much better that getting a per subproject scenario.  It also 
has a positive aspect of reducing the potential for private gardens.

>
> The main reason to make this here at Avalon is to have real contact with
> the users of Avalon, and have them actively partecipate in the component
> development. Avalon has had great benefit from the partecipation had in
> the last month of outer-avalon developers of projects that use Avalon,
> and we would like it to continue.
>
> This subproject would help create a clear and longstanding relationship
> with our users.


This is key point - putting in place somethig that supports the user 
community.

>
> More practically, it would unite Excalibur and Cornerstone, and make 
> it possible for James developers to fix the Cornerstone components 
> that are driving them mad directly in the repository, and facilitate 
> the usage and fixing of our components by interested Turbine developers.


+100.

>
> There were two issues brought up about this happening.
>
> Leo Simmons correctly reminded that there is an Apache Commons 
> project, that could make a cool repository for all Avalon Components 
> for all Apache projects.
>
> IMHO we are still far away from that possibility. I really don't think 
> that in the short-mid term Turbine or James developers would want to 
> move their stuff into that repo, because there is no real need. What 
> they would do, is to partecipate in the *generic* components, that we 
> would keep here, in Avalon Components.
>
> Then Stephen McConnell wrote:
>
>>
>> It is my understanding that the notion of an avalon-components is out 
>> of scope of the Avalon Project.
>>
>>  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;
>
>
> But as you also correctly point out:
>
>> Resolution of the conflict between this position and the existing 
>> Cornerstone and Apps CVS is addressed under the resolution:
>>
>>  RESOLVED, that the initial Avalon PMC be and hereby is tasked
>>  with the migration and rationalization of the Jakarta PMC
>>  Avalon subproject;
>
>
> That does not address the possibility of moving code outside of the
> project, or keeping it ourselves.


Agreed.
The point I was raising is that relative tio our current scope - there 
is an explicit action required by us to take a decision on this and that 
decision has a implication on us to go though a board ratification 
process becuase it touches on the questyion of Avalon scope.

>
> I think that the creation of Avalon Components is part of the " 
> migration and rationalization" objective that the board has given us. 


I agree that your proposal is within scope of rationalization.

>
>
> I have not yet recieved public answer from the question I gave to the 
> board about this. TO resolve this, I propose that we ask the board to 
> retify an addendum at the next meeting for our charter *if* they 
> decide that it's needed for this subproject creation:
>
>   RESOLVED, that the Avalon PMC be and hereby is responsible
>   for the creation and maintenance of software related to
>   component and service management, and components and services
>   themselves designed to operate in it, based on software licensed
>   to the Foundation;


I think we can enshance the wording a bit - but in pricipal - I think we 
should do this as part of a process of facilitating Avalon user support. 
 I also think that this is more about evolving and supporting users than 
establishing a component repository - but I must confess that the second 
item has its benefits - but it also has its downside.  Today - I'm +1 on 
introducing something that enables and empowers our user community and I 
think that it is the immediate priority.  Perhaps the question of a 
formal component repository is something to be addressed some time in 
the future although I am not averse to discussing it now.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net