You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by cm...@yahoo.com on 2001/02/26 17:53:27 UTC
My itch
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
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
Re: My itch
Posted by Ted Husted <ne...@husted.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?
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 Ted Husted <ne...@husted.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?
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 and Round 3
Posted by David Weinrich <dw...@home.com>.
On Mon, 26 Feb 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> >
> > +1 - I can say I agree 100%.
> >
> > Regarding peer review and "releasing" - if the component is used in a
> > product, it'll be released as part of the product.
> >
> > If it is productized and released as stand-alone - normal jakarta rules should apply.
>
> How about this then:
>
> --
>
> (1) scope of the subproject
>
> The subproject shall create and maintain packages written in the Java
> language, intended for use in server-related development, and designed
> to be used independently of any larger product or framework. Each
> package will be managed in the same manner as a larger Jakarta product.
>
> (1.5) interaction with other subprojects
>
> The subproject CVS will be available to all Jakarta committers as a
> sandbox for new packages. Before release
> to the public, a sandbox package must either be accepted to the library,
> or be sponsored by another Jakarta
> subproject. The subproject will also catalog packages available to the
> public through other Jakarta subprojects and ASF projects.
>
+1 for this + round 3 proposals
> --
>
> Should we stick with calling this the Library project, or something
> else, like Agora, Rupert, or Zarf?
>
I think library works for now. If there is one part of jakarta that we
want to be instantly recognizable for what it is, this should probably be
it ;)
> -T.
>
David
Re: My itch
Posted by cm...@yahoo.com.
> (1) scope of the subproject
>
> The subproject shall create and maintain packages written in the Java
> language, intended for use in server-related development, and designed
> to be used independently of any larger product or framework. Each
> package will be managed in the same manner as a larger Jakarta product.
>
> (1.5) interaction with other subprojects
>
> The subproject CVS will be available to all Jakarta committers as a
> sandbox for new packages. Before release
> to the public, a sandbox package must either be accepted to the library,
> or be sponsored by another Jakarta
> subproject. The subproject will also catalog packages available to the
> public through other Jakarta subprojects and ASF projects.
>
+1
> Should we stick with calling this the Library project, or something
> else, like Agora, Rupert, or Zarf?
The subproject CVS that is "available to all jakarta commiters as a
sandbox" is close enough to what I would like. Any name is fine - but if
we don't have a consensus on beeing open to all projects and commiters (
even as a sandbox as you propose ) - I wouldn't call it Library or Agora.
If we agree that duplication is permitted and the sandbox is shared and
open to everyone - library or agora would fit very well.
Costin
Re: My itch and Round 3
Posted by David Weinrich <dw...@home.com>.
On Mon, 26 Feb 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> >
> > +1 - I can say I agree 100%.
> >
> > Regarding peer review and "releasing" - if the component is used in a
> > product, it'll be released as part of the product.
> >
> > If it is productized and released as stand-alone - normal jakarta rules should apply.
>
> How about this then:
>
> --
>
> (1) scope of the subproject
>
> The subproject shall create and maintain packages written in the Java
> language, intended for use in server-related development, and designed
> to be used independently of any larger product or framework. Each
> package will be managed in the same manner as a larger Jakarta product.
>
> (1.5) interaction with other subprojects
>
> The subproject CVS will be available to all Jakarta committers as a
> sandbox for new packages. Before release
> to the public, a sandbox package must either be accepted to the library,
> or be sponsored by another Jakarta
> subproject. The subproject will also catalog packages available to the
> public through other Jakarta subprojects and ASF projects.
>
+1 for this + round 3 proposals
> --
>
> Should we stick with calling this the Library project, or something
> else, like Agora, Rupert, or Zarf?
>
I think library works for now. If there is one part of jakarta that we
want to be instantly recognizable for what it is, this should probably be
it ;)
> -T.
>
David
Re: My itch
Posted by cm...@yahoo.com.
> (1) scope of the subproject
>
> The subproject shall create and maintain packages written in the Java
> language, intended for use in server-related development, and designed
> to be used independently of any larger product or framework. Each
> package will be managed in the same manner as a larger Jakarta product.
>
> (1.5) interaction with other subprojects
>
> The subproject CVS will be available to all Jakarta committers as a
> sandbox for new packages. Before release
> to the public, a sandbox package must either be accepted to the library,
> or be sponsored by another Jakarta
> subproject. The subproject will also catalog packages available to the
> public through other Jakarta subprojects and ASF projects.
>
+1
> Should we stick with calling this the Library project, or something
> else, like Agora, Rupert, or Zarf?
The subproject CVS that is "available to all jakarta commiters as a
sandbox" is close enough to what I would like. Any name is fine - but if
we don't have a consensus on beeing open to all projects and commiters (
even as a sandbox as you propose ) - I wouldn't call it Library or Agora.
If we agree that duplication is permitted and the sandbox is shared and
open to everyone - library or agora would fit very well.
Costin
Re: My itch
Posted by Morgan Delagrange <md...@yahoo.com>.
Well, it sounds like a wild ride, but I'm willing to
give it a shot. +1.
--- Ted Husted <ne...@husted.com> wrote:
> cmanolache@yahoo.com wrote:
> >
> > +1 - I can say I agree 100%.
> >
> > Regarding peer review and "releasing" - if the
> component is used in a
> > product, it'll be released as part of the product.
> >
> > If it is productized and released as stand-alone -
> normal jakarta rules should apply.
>
> How about this then:
>
> --
>
> (1) scope of the subproject
>
> The subproject shall create and maintain packages
> written in the Java
> language, intended for use in server-related
> development, and designed
> to be used independently of any larger product or
> framework. Each
> package will be managed in the same manner as a
> larger Jakarta product.
>
> (1.5) interaction with other subprojects
>
> The subproject CVS will be available to all Jakarta
> committers as a
> sandbox for new packages. Before release
> to the public, a sandbox package must either be
> accepted to the library,
> or be sponsored by another Jakarta
> subproject. The subproject will also catalog
> packages available to the
> public through other Jakarta subprojects and ASF
> projects.
>
> --
>
> Should we stick with calling this the Library
> project, or something
> else, like Agora, Rupert, or Zarf?
>
> -T.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: My itch
Posted by Morgan Delagrange <md...@yahoo.com>.
Well, it sounds like a wild ride, but I'm willing to
give it a shot. +1.
--- Ted Husted <ne...@husted.com> wrote:
> cmanolache@yahoo.com wrote:
> >
> > +1 - I can say I agree 100%.
> >
> > Regarding peer review and "releasing" - if the
> component is used in a
> > product, it'll be released as part of the product.
> >
> > If it is productized and released as stand-alone -
> normal jakarta rules should apply.
>
> How about this then:
>
> --
>
> (1) scope of the subproject
>
> The subproject shall create and maintain packages
> written in the Java
> language, intended for use in server-related
> development, and designed
> to be used independently of any larger product or
> framework. Each
> package will be managed in the same manner as a
> larger Jakarta product.
>
> (1.5) interaction with other subprojects
>
> The subproject CVS will be available to all Jakarta
> committers as a
> sandbox for new packages. Before release
> to the public, a sandbox package must either be
> accepted to the library,
> or be sponsored by another Jakarta
> subproject. The subproject will also catalog
> packages available to the
> public through other Jakarta subprojects and ASF
> projects.
>
> --
>
> Should we stick with calling this the Library
> project, or something
> else, like Agora, Rupert, or Zarf?
>
> -T.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: My itch
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
>
> +1 - I can say I agree 100%.
>
> Regarding peer review and "releasing" - if the component is used in a
> product, it'll be released as part of the product.
>
> If it is productized and released as stand-alone - normal jakarta rules should apply.
How about this then:
--
(1) scope of the subproject
The subproject shall create and maintain packages written in the Java
language, intended for use in server-related development, and designed
to be used independently of any larger product or framework. Each
package will be managed in the same manner as a larger Jakarta product.
(1.5) interaction with other subprojects
The subproject CVS will be available to all Jakarta committers as a
sandbox for new packages. Before release
to the public, a sandbox package must either be accepted to the library,
or be sponsored by another Jakarta
subproject. The subproject will also catalog packages available to the
public through other Jakarta subprojects and ASF projects.
--
Should we stick with calling this the Library project, or something
else, like Agora, Rupert, or Zarf?
-T.
Re: My itch
Posted by David Weinrich <dw...@home.com>.
On Mon, 26 Feb 2001, Craig R. McClanahan wrote:
> cmanolache@yahoo.com 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
>
Re: My itch
Posted by cm...@yahoo.com.
> >
> > 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
Re: My itch
Posted by David Weinrich <dw...@home.com>.
On Mon, 26 Feb 2001, Craig R. McClanahan wrote:
> cmanolache@yahoo.com 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
>
Re: My itch
Posted by cm...@yahoo.com.
> >
> > 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
Re: My itch
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
cmanolache@yahoo.com 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.
>
> 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
Re: My itch
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
>
> +1 - I can say I agree 100%.
>
> Regarding peer review and "releasing" - if the component is used in a
> product, it'll be released as part of the product.
>
> If it is productized and released as stand-alone - normal jakarta rules should apply.
How about this then:
--
(1) scope of the subproject
The subproject shall create and maintain packages written in the Java
language, intended for use in server-related development, and designed
to be used independently of any larger product or framework. Each
package will be managed in the same manner as a larger Jakarta product.
(1.5) interaction with other subprojects
The subproject CVS will be available to all Jakarta committers as a
sandbox for new packages. Before release
to the public, a sandbox package must either be accepted to the library,
or be sponsored by another Jakarta
subproject. The subproject will also catalog packages available to the
public through other Jakarta subprojects and ASF projects.
--
Should we stick with calling this the Library project, or something
else, like Agora, Rupert, or Zarf?
-T.
Re: My itch
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
cmanolache@yahoo.com 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.
>
> 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
Re: My itch
Posted by cm...@yahoo.com.
+1 - I can say I agree 100%.
Regarding peer review and "releasing" - if the component is used in a
product, it'll be released as part of the product.
If it is productized and released as stand-alone - normal jakarta rules
should apply.
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
( 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 ).
Costin
> The incubator CVS is another recurring theme.
>
> We have a good example right now. Geir and some others might like to
> work on a database connection pool. But there's no where in Jakarta land
> they can easily do that now. We can't get a CVS without a proposal, and
> we can't get a codebase without a CVS. (Whither SourceForge ..)
>
> Costin wanted to try this with Jakarta-Util, but the vote tanked.
>
> Personally, I have no problem with everyone being enrolled to the
> library CVS, or enrolled upon request (if they are already a committer).
> My only stipulation would be to encourage an etiquette where people
> added themselves to the Status file before committing to an existing
> package -- so that people feel like they are signing up for something.
> But creating new, test packages would be fair game.
>
> The only thing we have to watch for is that there is some type of peer
> review before a package goes into public distribution under the Apache
> name. Jakarta != SourceForge. This is where a proposal and/or vote would
> come in. But, anyone can check a revolution out of the CVS, we're just
> not saying it's ready for prime time.
>
> And, for the purposes of this proposal, you're a committer here ;-) Your
> vote counts as much as any other on this.
>
>
> -T.
>
> David Weinrich wrote:
> > 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.
> >
>
Re: My itch
Posted by cm...@yahoo.com.
+1 - I can say I agree 100%.
Regarding peer review and "releasing" - if the component is used in a
product, it'll be released as part of the product.
If it is productized and released as stand-alone - normal jakarta rules
should apply.
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
( 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 ).
Costin
> The incubator CVS is another recurring theme.
>
> We have a good example right now. Geir and some others might like to
> work on a database connection pool. But there's no where in Jakarta land
> they can easily do that now. We can't get a CVS without a proposal, and
> we can't get a codebase without a CVS. (Whither SourceForge ..)
>
> Costin wanted to try this with Jakarta-Util, but the vote tanked.
>
> Personally, I have no problem with everyone being enrolled to the
> library CVS, or enrolled upon request (if they are already a committer).
> My only stipulation would be to encourage an etiquette where people
> added themselves to the Status file before committing to an existing
> package -- so that people feel like they are signing up for something.
> But creating new, test packages would be fair game.
>
> The only thing we have to watch for is that there is some type of peer
> review before a package goes into public distribution under the Apache
> name. Jakarta != SourceForge. This is where a proposal and/or vote would
> come in. But, anyone can check a revolution out of the CVS, we're just
> not saying it's ready for prime time.
>
> And, for the purposes of this proposal, you're a committer here ;-) Your
> vote counts as much as any other on this.
>
>
> -T.
>
> David Weinrich wrote:
> > 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.
> >
>
Re: My itch
Posted by Ted Husted <ne...@husted.com>.
The incubator CVS is another recurring theme.
We have a good example right now. Geir and some others might like to
work on a database connection pool. But there's no where in Jakarta land
they can easily do that now. We can't get a CVS without a proposal, and
we can't get a codebase without a CVS. (Whither SourceForge ..)
Costin wanted to try this with Jakarta-Util, but the vote tanked.
Personally, I have no problem with everyone being enrolled to the
library CVS, or enrolled upon request (if they are already a committer).
My only stipulation would be to encourage an etiquette where people
added themselves to the Status file before committing to an existing
package -- so that people feel like they are signing up for something.
But creating new, test packages would be fair game.
The only thing we have to watch for is that there is some type of peer
review before a package goes into public distribution under the Apache
name. Jakarta != SourceForge. This is where a proposal and/or vote would
come in. But, anyone can check a revolution out of the CVS, we're just
not saying it's ready for prime time.
And, for the purposes of this proposal, you're a committer here ;-) Your
vote counts as much as any other on this.
-T.
David Weinrich wrote:
> 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.
>
Re: My itch
Posted by Ted Husted <ne...@husted.com>.
The incubator CVS is another recurring theme.
We have a good example right now. Geir and some others might like to
work on a database connection pool. But there's no where in Jakarta land
they can easily do that now. We can't get a CVS without a proposal, and
we can't get a codebase without a CVS. (Whither SourceForge ..)
Costin wanted to try this with Jakarta-Util, but the vote tanked.
Personally, I have no problem with everyone being enrolled to the
library CVS, or enrolled upon request (if they are already a committer).
My only stipulation would be to encourage an etiquette where people
added themselves to the Status file before committing to an existing
package -- so that people feel like they are signing up for something.
But creating new, test packages would be fair game.
The only thing we have to watch for is that there is some type of peer
review before a package goes into public distribution under the Apache
name. Jakarta != SourceForge. This is where a proposal and/or vote would
come in. But, anyone can check a revolution out of the CVS, we're just
not saying it's ready for prime time.
And, for the purposes of this proposal, you're a committer here ;-) Your
vote counts as much as any other on this.
-T.
David Weinrich wrote:
> 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.
>
Re: My itch
Posted by David Weinrich <dw...@home.com>.
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 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
>
>
Re: My itch
Posted by David Weinrich <dw...@home.com>.
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 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
>
>