Ok, but why do we have to actually move the packages?
Why can't Agora host an online catalog where it would list packages that
products have designed for independent use?
The Jakarta committers would have instant access to the catalog, and
whatever they post is listed instantly, without any prior review
process. (Lazy consensus.)
This will make us all more aware of what is buried in other subprojects,
and encourage more people to cross-commit, without making any
infrastructure changes. Heck, we could just suggest that the catalog be
made part of the jakarta-site2 and not even make it a separate
subproject. (And, obviously, I'm personally +1 on the catalog.)
[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
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
