You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Ted Husted <ne...@husted.com> on 2001/02/26 18:33:15 UTC

Re: My itch

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.)

cmanolache@yahoo.com 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/

Re: My itch

Posted by cm...@yahoo.com.
> anything else. Like Jon said elsewhere, how many proposed committers
> have ever been rejected? And, unlike HTTP, you can nominate yourself
> here. If we publicize the existing components more, then we might have
> more committers walking up to another subproject, and saying "mind if I
> help you with that?"

- I never saw anyone doing that ( propose himself )
- AFAIK the current rules require a number of contributions before beeing
proposed
- commiters walking up to another subproject would be great, but I think
at this moment it would be better ( and safer ) to try "commiters walking 
to a common/shared subproject". 

I think this discussion showed there are significant bariers between
projects, and people don't feel very comfortable with lower walls for
commiters.


> I think the big fix is to encourage committers to join more subprojects,
> if only on a very limited basis. (Like say, Morgan wanting to work on
> your custom tag.) Then, we would have a more even "tone" throughout
> Jakarta, and more interaction. 

I share the goal - but my feeling is that's not going to happen that
easily, and would be much easier if we would try to build some trust by
working in a common repository. Again - I would be happy if you prove I'm
wrong.

I don't think the issue is to join more subprojects ( I hardly have time
for one), but to find things that are common and divide the work on them.

Costin




Re: My itch

Posted by cm...@yahoo.com.
> anything else. Like Jon said elsewhere, how many proposed committers
> have ever been rejected? And, unlike HTTP, you can nominate yourself
> here. If we publicize the existing components more, then we might have
> more committers walking up to another subproject, and saying "mind if I
> help you with that?"

- I never saw anyone doing that ( propose himself )
- AFAIK the current rules require a number of contributions before beeing
proposed
- commiters walking up to another subproject would be great, but I think
at this moment it would be better ( and safer ) to try "commiters walking 
to a common/shared subproject". 

I think this discussion showed there are significant bariers between
projects, and people don't feel very comfortable with lower walls for
commiters.


> I think the big fix is to encourage committers to join more subprojects,
> if only on a very limited basis. (Like say, Morgan wanting to work on
> your custom tag.) Then, we would have a more even "tone" throughout
> Jakarta, and more interaction. 

I share the goal - but my feeling is that's not going to happen that
easily, and would be much easier if we would try to build some trust by
working in a common repository. Again - I would be happy if you prove I'm
wrong.

I don't think the issue is to join more subprojects ( I hardly have time
for one), but to find things that are common and divide the work on them.

Costin




Re: My itch

Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> So everyone can be able to work on it ( fix the bugs, enhance, etc. ) and
> make sure all sides realize this. ( plus, reduce the feeling that a
> component "belongs" to  a project )

Everyone should be able work on a component now ;-), committers,
developers, and users alike.  Everyone's contribution is valued (I mean,
that's what the rules say ;-).

I think in some subprojects this happens a lot. In other places, it
might happen less. It's probably more of a "tone" issue more than
anything else. Like Jon said elsewhere, how many proposed committers
have ever been rejected? And, unlike HTTP, you can nominate yourself
here. If we publicize the existing components more, then we might have
more committers walking up to another subproject, and saying "mind if I
help you with that?"

I think the big fix is to encourage committers to join more subprojects,
if only on a very limited basis. (Like say, Morgan wanting to work on
your custom tag.) Then, we would have a more even "tone" throughout
Jakarta, and more interaction. 

-T.

Re: My itch

Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> So everyone can be able to work on it ( fix the bugs, enhance, etc. ) and
> make sure all sides realize this. ( plus, reduce the feeling that a
> component "belongs" to  a project )

Everyone should be able work on a component now ;-), committers,
developers, and users alike.  Everyone's contribution is valued (I mean,
that's what the rules say ;-).

I think in some subprojects this happens a lot. In other places, it
might happen less. It's probably more of a "tone" issue more than
anything else. Like Jon said elsewhere, how many proposed committers
have ever been rejected? And, unlike HTTP, you can nominate yourself
here. If we publicize the existing components more, then we might have
more committers walking up to another subproject, and saying "mind if I
help you with that?"

I think the big fix is to encourage committers to join more subprojects,
if only on a very limited basis. (Like say, Morgan wanting to work on
your custom tag.) Then, we would have a more even "tone" throughout
Jakarta, and more interaction. 

-T.

Re: My itch

Posted by cm...@yahoo.com.
> 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?

So everyone can be able to work on it ( fix the bugs, enhance, etc. ) and
make sure all sides realize this. ( plus, reduce the feeling that a
component "belongs" to  a project )

I think the Library can do that - the goal of Agora is to have projects
cooperate on the development of non-specific code, and this can't work if
the code remain in the original repository ( cvs access, rules, etc need
to be special ). 


> The Jakarta committers would have instant access to the catalog, and
> whatever they post is listed instantly, without any prior review
> process. (Lazy consensus.)

Great for the library - for Agora we need commiters to be able to make
changes and commits to the components ( that's the goal ).


> This will make us all more aware of what is buried in other subprojects,
> and encourage more people to cross-commit, without making any

That's a great step forward in any case - but Agora should un-bury the
code.

Plus, moving code to agora should be an "active" decision, based on a vote
and the benefits it may add to the project - and then work will be
require to remove deps, etc. 


Costin


Re: My itch

Posted by cm...@yahoo.com.
> 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?

So everyone can be able to work on it ( fix the bugs, enhance, etc. ) and
make sure all sides realize this. ( plus, reduce the feeling that a
component "belongs" to  a project )

I think the Library can do that - the goal of Agora is to have projects
cooperate on the development of non-specific code, and this can't work if
the code remain in the original repository ( cvs access, rules, etc need
to be special ). 


> The Jakarta committers would have instant access to the catalog, and
> whatever they post is listed instantly, without any prior review
> process. (Lazy consensus.)

Great for the library - for Agora we need commiters to be able to make
changes and commits to the components ( that's the goal ).


> This will make us all more aware of what is buried in other subprojects,
> and encourage more people to cross-commit, without making any

That's a great step forward in any case - but Agora should un-bury the
code.

Plus, moving code to agora should be an "active" decision, based on a vote
and the benefits it may add to the project - and then work will be
require to remove deps, etc. 


Costin