On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
...snipped for no good reason...
>
> I'm all for setting things up so that people can do what they need. My
> discomfort is the current proposal combines three use cases:
>
> (1) New experimental code that is not available to the public (and
> is not subject to releases or versioning).
>
> (2) Code that has been released as part of a subproject (but does
> not have a released state of its own).
>
> (3) Code that has been accepted into the Commons (and therefore has
> its own release schedule and versioning).
>
> into only two places where the code might live:
>
> (A) sandbox - for cases 1 and 2.
>
> (B) commons - for case 3.
>
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
>
> (b) Add a third reposiory (I guess it would be agora according to the
> current vocabulary) for use case 2.
>
> I would prefer we choose (a), although I could live with (b).
>
> > Costin
> >
> >
>
> Craig
>
I have to agree with you on this one, the case where a code is in the
state of (2) above seems to invite problems. What seems to be a decent
compromise to me is to allow a status to be attached to each a component:
experimental: not fit for public consumption. Code that is in the process
of being tested and matured.
current: Code that has reached a reasonable amount of stability. It would
almost be reasonable for a project to include this version of code with a
pre-beta product, with assumptions similar to (a) above.
stable/beta: Code that has a stable api and is nearing release quality. It
would again be reasonable for a project to include this code in the
beta-release of a product, with assumptions that reaching a release state
on this code ( either rolling the code into the product if only one
project uses it or putting it in the library ) is something of a
prerequisite for completing the beta-testing of the product.
release: Code that is or will be used in one or more released versions of
a jakarta product. I'm guessing most code in this state will be entered
into the library.
( pardon the FreeBSD-ish wordings, that model seemed to fit this
discussion well )
Now my questions are these:
1) What can be done to prevent the situation Craig describes above, where
one or more jakarta project(s) use different versions of code from <insert
name of shared CVS here>?
2) In what cases would people work together on code, but not want to go
the extra ten miles to release the code as a 'product' or 'component' ( or
any other suitable word)?
3) What should be the criteria for what is considered 'fit for public
consumption' code?
These are the issues that cloud my understanding of the issue right now,
so I am trying to understand how people ( with more experience ;)
interpret and would solve those questions.
As far as names go, sandbox was a word chosen fairly quickly, and I agree
that it has too many meanings. Agora would be a good name for the shared CVS.
David
