On Thu, 15 Mar 2001, Craig R. McClanahan wrote:
> > The experimental code is experimental - when it starts to be used in a
> > stable release of a project it's no longer experimental.
> >
>
> Agreed ... hence the need for a clear distinction in how non-experimental
> code is organized and handled.
Agora was not intended for experimental code. This is something that was
added - and I'm ok with removing it ( i.e. keep the sandbox for the code
that is shared and used in real products ).
This would make things much cleaner - the code in agora that is included
in a released project does have the testing and support of (at least) one
project.
Agora is intended to allow projects to make the decisions that are best
for themself - so we shouldn't force any particular solution.
> > > (2) Code that has been released as part of a subproject (but does
> > > not have a released state of its own).
> >
> > That's what I'm interested in and what Agora is supposed to do.
> > Put this code in a place where other projects can share and use without
> > any barier.
> >
>
> Costin, how is your view of this use case different from (3) below? Why
> would it not just be proposed to the Commons, and set up with its own
> formal release structure?
>
> Even if only one subproject makes use of it initially, making the code
> available for reuse seems to be the whole point of why we are here.
Yes - and there are 2 ways to do that. One is to try to create a package
and maintain in ( the commons), and one is to co-develop the component
with other projects.
It's about control to the component - I think the main problem and the
reason for the current duplication is exactly that.
In a way, that was the problem with Avalon - and I don't see anything
different in the commons. There is a community ( avalon, commons,
individual projects, etc) that maintains some components. Of course, we
all claim we are open and listen to the users and don't do incompatible
changes - but as you know sometimes ( or most of the times ) this is not
true - more features are added to the component, etc.
Repeating Avalon will not change anything. The Agora is supposed to be
different in the fact that the components are "owned" by the projects that
are using it. It's a whole different thing.
Example: a thread pool. It may be used in tc3.3, tc4.0, other projects.
If it's part of the commons, it's commiters may decide to optimize it or
add some features. This will result in tensions, and probably each project
will decide it's better to implement a thread pool they control.
If it's in agora, the commiters for the thread pool are the projects that
are using it - a change will have to be aproved by all affected people (
even if they are not the thread pool developers ).
> Why can't they do that in the Commons? Those packages are going to be
> maintained, and enhanced, and released, as well. What's the difference?
Control. Who decides the future and changes of the component. Who supports
it.
Some may prefer to use components supported by a dedicated group (
commons, avalon, a project ). Some may prefer to use components in Agora,
where they have control over the evolution of the component.
Costin
