On Thu, 15 Mar 2001, Ted Husted wrote:

> [EMAIL PROTECTED] wrote:
> > Depends on how do you define "closed to the public".
> > 
> > Something can't get out of the sandbox on "it's own" - you can't just
> > start something and then release it to public. I agree with that.
> > 
> > But in the same way as a component can be released as result of a vote
> > of library commiters ( who assume the responsibilty to maintain it and
> > insure the quality ), it can be as well released by the result of a vote
> > of another project.
> 
> Agreed. 
> 
> But after they vote to release it, is the public going to be able to
> download it separately? 
> 
> Or is it only going to be available as part of the build for the
> respective products using the codebase?

It's a choice to be made by the project - not a pre-determined answer. 
The commons is not the only project that can release components ( after
all Avalon is doing exactly that ).

But this is the whole point - to let projects decide how to use and share
components.  



> 
> [EMAIL PROTECTED] wrote:
> > The goal is to keep the code in a common place so more projects
> > can cooperate on it, and that's why we need a common repository where all
> > projects have equal access.
> 
> Where this all break down for me is that subprojects are a workgroup
> tasked to create and maintain a particular product. Committers can and
> do work on multiple products. The focus needs to be on helping
> * committers * cooperate regardless of what product they happen to be 
> working on
> 
> The Commons model is designed so that volunteers can work together on a
> package that can be used by more than one product. The difference
> between this and Agora seems to be that subprojects are being promoted
> to entities with some kind of a vote. I don't believe that this is wise. 
> The code belongs to the committers, who work together on products. We
> need
> to think in terms of committers who build products, and avoid
> reinforcing the idea that Jakarta is a collection of competing tribes.

One more and I'll give up...

It's obvious you prefer one development model, with components developed
by a group of commiters who control it's fate. 

I prefer another - where control is shared by the different projects that
are using the component. 

And the issue here is that people who prefer the first model are not
willing to tolerate other solutions.


Costin 

Reply via email to