avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Proposal] Phoenix no longer reference container
Date Fri, 22 Nov 2002 13:49:58 GMT

> From: Sam Ruby [mailto:rubys@apache.org] 
> Leo Sutic wrote:
> > And concensus across all of Avalon may not be the right 
> > method for it.
> Wrong answer.  Try again.
> "doesn't pay any paychecks" and the possibility that somebody 
> may "lose some advertising points" are not valid reasons for 
> having multiple containers.
> If somebody has an expedient business need for a code base 
> which is not based on consensus, then they simply take a 
> snapshot and enhance it elsewhere.  Ideally, they feed back 
> the best portions of their results back into the community.  
> But if they don't, that's OK too. After all, this isn't GPL.
> - Sam Ruby

Yet the way such concensus based development would work may not 
be ideal - in particular, the scope of the concensus may be too

The problem, as I see it is this:

 + We need a very stable framework. Concensus here is vital.

 + We can not develop a framework from first assumptions,
   that is, the framework must be tried by users so we get

 + In order to have the product tested by users, we must have
   a compelling product.

 + As users will only consider a product compelling if it solves
   their needs, that product will have to evolve to meet those 

 + The rate of evolution for the product and the framework
   will be different. The framework will only adopt the parts
   of the product that "worked", and will thus evolve more 

Now, how do we handle those shear forces we have due to the
different rates of evolution?

I admit that my remark on concensus vs. paychecks was out of line
and stupid, but you yourself state that:

    In other words, the creation of such internal forks is to be 
    done based on consensus on the scope, visibility, and design 
    direction of such an effort.  

Meaning that (as I interpret it), as long as Phoenix has a 

 + defined scope based on concensus.

 + sticks to that scope

 + clear understanding of its relation to Avalon

we should be fine.

A question: what is the smallest unit that can claim concensus?
Avalon does not need the consensus of Jakarta-Commons, we can
vote ourselves. At the same time, I don't want one person
creating a subproject of Avalon, declaring that he owns that
code and that his own opinion is equal to concensus.

In short, is there any way to decouple Phoenix from Avalon
in such a way so that *all* PMC members need not vote on
*every* change to Phoenix, yet keep Phoenix from sliding
away to a little isolated group of its own?


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