On Mon, 26 Feb 2001, Craig R. McClanahan wrote:
> [EMAIL PROTECTED] wrote:
>
> >
> > Regarding peer review and "releasing" - if the component is used in a
> > product, it'll be released as part of the product.
>
> Delurking ...
>
> One caution along these lines -- this will require Jakarta project
> committers to
> behave differently with respect to "library"-sourced code than they do
> at
> external projects we have dependencies on. As a Tomcat committer, do I
> look at
> the code inside jakarta-regexp (which 4.0 depends on), or log4j (if/when
> logging
> support is migrated to that), or Ant? No ... once I have determined
> that the
> projects meets my needs, I count on the committers of those projects to
> do a good
> job of release management, and then rely on released versions. But now,
> I have
> to look at (some of) this code differently, because it is not being
> "released" in
> the same sense.
>
> In the initial cases, this will not make a huge amount of difference --
> the
> primary authors of the shared code are likely to be the same folks as
> the
> committers on the first project that uses it -- but the *second* project
> that
> comes along and uses that code needs to be aware that they need to treat
> it (for
> code management purposes) as a potential code contribution, not as a
> released
> "product". If that's what we want, we should make that clear in the
> docs for the
> overall library, because it will be a habit change versus what people
> are used to
> doing.
>
> For me personally, I'm going to treat code I contribute to in the shared
> environment more as a "product" than an "available code base", but to
> each their
> own.
>
This is very closely aligned to the discussion about the library vs.
sandbox. For most 'projects' within the 'project' ( sorry, too tired to
find a better word right now ;) the natural progression will be to
productize the code ( with the standards of testing, documentation, and
support that we've been discussing ) and place it in the library when it
has reached a stable point.
> >
> > If it is productized and released as stand-alone - normal jakarta rules
> > should apply.
>
> +1
>
> >
> > In the STATUS file we should list all releases the component is part of,
> > and a "component status":
> > - experimental
> > - not released
> > - released as part of project foo.x.y
> > - released standalone
>
> Does "experimental" correspond to "code that you're welcome to use, but
> you had
> better review it for yourself" per the above discussion?
>
> +1 on status marking, although the "released as part of" stuff is going
> to be
> hard to keep up to date unless the using project's committers do it.
>
> >
> > ( and of course, my initial proposal that any project should be able to
> > tag the workspace when they have a release, so they can re-create the
> > build later and be able to refer to the state of the component when it was
> > included in the project release ).
>
> +1.
>
> >
> > Costin
>
> Craig
>
