> >
> > 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
Well, that was exactly my point at the beginning of this thread.
One of the goals was to improve cross-project communication, and
improve the common code we all depend on.
It's a win-win situation - the component will benefit a lot if you,
as tomcat committer, would review the code and feed back sugestions
or improvements. And each project would benefit from better components.
Of course, you are not required to look at the code - if the component
does what you need, it's perfect. But you still have a vote
on the library - protecting you from changes that might happen
and affect tomcat ( each component evolves - most of the time for
better :-)
This proposal was made for the components shared between projects,
for example XmlMapper or GTest or smaller loggers - where more than one
project is working on such components, i.e. we look at the code
anyway. By sharing it in the library/agora we just poll the
resources. For regexp or log4j - or "graduated" components
that have their own maintainers - this is less important.
> 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.
This "some of" the code will fall in 2 categories:
- code that originates in tomcat, and is now shared
- code that is shared by another project, and would have been duplicated
in tomcat ( or code that is shared by another project, is needed in
tomcat, but needs more work - it's missing some features or doesn't fit
well ).
Both cases would have required special attention anyway, but by sharing
you might reduce the ammount of work ( or divide it with others )
In time many of the components will "graduate" - or just become stable.
In any case - the work and review will be split among all projects
that are using a component.
> 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.
That was part of my original proposal - to have multiple projects share
code and work on the code. Creating "stable" components is also a goal for
many people - but from a project perspective this should be the
"lucky" case, when a stable component is available without any work
required.
> 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.
Yes, each shared component should be treated as a mini-project, with the
goal of becoming a "product" - just that by "sharing" it you agree to let
other project shape the final product, so it can be used by more projects.
> Does "experimental" correspond to "code that you're welcome to use, but
> you had better review it for yourself" per the above discussion?
Probably so. I think that a component that "makes it" into a project
stable release will no longer be "experimental" - it should have passed at
least one beta cycle and testing with the embeding project.
> +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.
I think that would have to happen - each project needs to at least
tag the library workspace that it uses when it has a release ( to be able
to reproduce the build at least ).
Costin
