On Thu, 15 Mar 2001 [EMAIL PROTECTED] wrote:
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > [EMAIL PROTECTED] wrote:
> > ....
> > >
> > > That's why we need the extra " or sponsored by a jakarta subproject".
> >
> > I don't think so. I think that additional phrase will lead us back to
> > the current situation. As one of the problems that I hope Commons would
> > solve is making sure that 'released' components are documented,
> > installable and supported. If it's just a tagged set of classes in the
> > sandbox, we are back to the same problem we have already - released code
> > that a project depends upon that is not the projects main 'deliverable'
> > is undocumented, not independantly buildable, testable, and installable,
> > and largely hidden from public view because it's not separated and
> > promoted.
>
> Than what's the problem ??? You think the problem the commons would
> resolve is "released" components - you have that.
>
> Why don't you let other people to try a different thing ? I am interested
> in sharing the work on some common components - I don't care too much
> about releasing the components, it is not my main goal. I think this will
> happen as a side effect, because the code will be subject to a bigger
> community and in direct contact with the projects using it.
>
Why does this have to be one or the other? You don't care about releasing
the components, but others may. The work that will be done here can
benefit those who want to release components and those who desire to put
the common code back in their projects for release inside the
project. Again this comes down to the 'One and Only Acceptable Goal for
the Project' argument, which I think is counterproductive and not
neccessary.
> But the fundamental issue is this intolerance I find again and again and
> again in jakarta - why does everyone things that there is only one
> solution and one way to do something ?
>
> It is very likely that agora will fail - as far as I can tell intolerance
> is the rule here, and Agora's can't succeed in such environment. But we
> can try - maybe there are people who can repect other's ideas and not try
> to impose their will and solution.
>
Intolerance is a problem, but please understand that trying to limit the
project to your exact need/vision is yet another form of intolerance.
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
>
Again, we don't need a set of tribes within the project. The library is
intended to allow those people who want to put the extra effort into
making a component a 'product' to do so. This existing does not exclude
having a common CVS or whatever other goals you want. Please don't attach
or impose a perceived 'judgement' or 'attitude' where one doesn't exist.
> Your development model is wonderful - but it's not the only one.
>
That works both ways. If we insist that this can only work for strict
interpretation of a singular goal, that doesn't say much about building
community or assisting in cooperation.
> Costin
>
>
>
> >
> > > Removing this option will alter the original proposal in a significant way
> > > - those words were added to reach a compromise, and by transforming the
> > > agora into a play-ground the whole thing changes.
> >
> > Why? There isn't much real difference between 'play-ground' and 'place
> > to collaborate on unreleased components' as far as I can tell. It's a
> > subjective distinction, isn't it?
> >
> > > In which case I think we are back to the initial position - as the
> > > original vote on library-dev was based on the assumption that jakarta
> > > subprojects can release and cooperate on sandbox projects, and the sandbox
> > > was supposed to be an sharing place, not a playground.
> >
> > Right - but there should be something to release - just tagging a
> > collection of classes doesn't a release make, for the purposes of the
> > Commons project.
> >
> > geir
> >
> >
>
>
David
