At the risk of being a pain in the ass, -1 to the proposal ( yeah I know
it's a non-commiter vote but... ) for the following reason: in all of the
discussions so far on this list, I have yet to see the goals and ideals
between the various different proposals be *that* different. If the end
result of all of this is that we have created two more camps/tribes with
yet more walls between them, we have lost.
So here is my counter-proposal: create a jakarta project with two parts,
the 'agora' or 'sandbox' or 'incubator' part and the 'library' part. The
sandbox is a place where anyone can start a revolution or evolution if the
goal of the revolution or evolution is to promote reuse within jakarta as
a whole. The library is a place to put components developed in the sandbox
that have reached maturity and satisfy the fairly straightforward
requirements that have been discussed so far.
I think this natural division within *one* project satisfies a few
problems that having either one without the other or having two seperate
projects handling these would create:
* End users expect/need/want products with a stable api and good docs.
* Jakarta committers need a place to get together and share ideas or code
without the baggage and/or politics that would be required by coming
together in the context of one or the other projects.
* The barrier of moving the 'mature' product from a seperate project
sandbox into the library would be unnecessarily high...and pretty much
opposite of the ideals that started this discussion.
* One of the purposes of these discussions has been to bring the community
closer together. As I stated above, if we can't find a common ground on
this one goal, we have failed.
* The development of a good component that does one thing very well
benefits from the participation of the experts from *all* of the projects
that currently implement the components tasks internally. Creating a
process that slows down or overformalizes the startup of these efforts
will make it *not* happen.
So once again please consider this option:
* One project with two parts, a sandbox and a library.
* The sandbox is low barrier of entry and informal, while staying within
the goals and guidelines of the jakarta project.
* The library has well defined standards of documentation and testing and
is a repository for *stable* components.
* At the point where a component is ready to move from the sandbox into
the library, a mini-proposal is submitted to the list, with a list of the
people who will become the caretakers of the component.
from there I will defer to the people with more experience and knowledge,
but I think the general idea benefits everyone and forms a nice compromise
that will be a step forward and not back.
David Weinrich
On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
> This is in a way related with the library project, and I'm asking you for
> feedback. I'll not make a formal proposal until tomcat 3.3 is released, as
> I don't want more distractions.
>
> The problem:
> In most projects, a lot of code (1/3...1/2 ? ) is "general" and not
> specific to the main project goal. For example: logging, configuration,
> i18n, string and file utils.
>
> My itch:
>
> Find a way to share the work of maintaining and developing this code among
> projects ( which is very different from the library itch - which is
> creating components that could be used by projects ).
>
> In other words - my "driving" goal is not creating the components, but
> finding ways for different projects to split the work ( and thus reducing
> my work, and having more choices for the components I use).
>
> The main benefit for jakarta will be that creating a common place where
> projects can share will increase the exchanges between projects and
> "mix" commiters - thus building a "jakarta-level" community.
>
> My proposal:
>
> Create a new CVS repository ( let's say "revolutionary" ), with a set of
> rules tailored to solve the existing concerns. Tunning the rules and
> creating a "special" place is (IMHO) the only way to get this colaboration
> among projects.
>
> Let's call this "agora" ( until we find a better name ).
>
> 1. All jakarta commiters will be commiters on this project.
>
> Justification: I'm not proposing this for all projects - just for this
> repository. I don't think it's right ( at this moment ) to extend this to
> anything else, but it is essential for the success of the "agora" - we
> want jakarta commiters to share work and use, everyone should know he is
> part of this ( by default :-).
>
> 2. Any projects can create an "agora" component, by moving an existing
> part and agreeing to those rules - no vote on agora is needed.
>
> Justification: Agora is supposed to help projects share components ( both
> work and use ). The decision to share should be taken by the source
> project, and doesn't need to be "aproved" by any other entity.
>
> 3. By placing a component in the common repository, a project will get
> more "eyeballs" and share the maintainance and development of the
> component. In exchange, it will have to share decisions on the component
> with other projects.
>
> Justification: This is critical - this should reduce the concerns of
> projects that want to reuse a component and are afraid the component will
> change ( like it happened in the past so many times ). Since all projects
> will share the control of the component - the evolution can happen ( if
> all parties agree ) and incompatibities are minimized ( since all parties
> have control ). Note that I'm talking only about the projects that are
> actually using the component - and are affected by any change in the
> component.
>
> 4. Duplication is good.
>
> Justification: This will allow choice and reduce potential conflicts. If
> development of a component becomes conflicting - spliting it will allow 2
> more specialized components ( for different needs ) - which is good.
> By having multiple solutions in the same place, the diferences will be
> more visible and will allow better sharing of ideas and common interfaces.
>
> That's it.
>
> I think it's a win-win-win situation - the projects that decide to share
> code will benefit by sharing work and getting more "eyes" for the
> components, the projects that decide to use shared components will get
> better code and choices, and the components themself will benefit because
> more people will work on them and will be exposed to needs from other
> projects.
>
> In time, some components may mature and "graduate" into the library -
> where the goal is to have "production-level" components. Agora should just
> create a place for sharing - with focus on making the sharing work, while
> the library can focus on components and code.
>
> What do you think ?
>
> Costin
>
>
