You are viewing a plain text version of this content. The canonical link for it is here.
Posted to library-dev@jakarta.apache.org by Ted Husted <ne...@husted.com> on 2001/02/22 12:41:44 UTC
[POLL] General Consensus, Round 2
(1)
OLD BUSINESS
To finalize the first round, I'd like to get a majority vote on these
revised points of consensus. I believe these points represent the
consensus opinion. In the interest of unity, if possible, please provide
a single vote on the points as a block.
This poll will expire in 5 days, or when the committers on the active
roster (below) have responded.
+ The primary unit of reuse and release is the package.
+ The package library is not a framework but a repository of codebases
designed to be shared.
+ Each package must have a clearly defined purpose, scope, and API -- Do
one thing well, and keep your contracts.
+ Each library package is treated as a product in its own right.
- - Each package has its own status file, release schedule, version
number, QA tests, documentation, mailing list, and bug category.
- - Each package must clearly specify any external dependencies,
including any other library packages, and the earliest JDK version
required.
- - - External dependencies on optional and third-party codebases should
be minimized.
+ Each package maintains a list of its active committers in its status
file.
+ The packages should use a standard scheme for versioning, QA tests,
and directory layouts, and a common format for documentation and Ant
build files.
+ The packages should fit within a unified package hierarchy.
+ In general, packages should define an abstract interface, and provide
one or more implementations of that interface.
+ The packages should have boring functional names. Implementations may
choose more "exciting" designations.
+ Packages are encouraged to either use JavaBeans as core objects, a
JavaBean-style API, or to provide an optional JavaBean wrapper.
+ External configuration files are discouraged, but if required, XML
format files are preferred for configuration options.
+ The package library subproject shall be proposed as a Jakarta
subproject.
+ Each package will be hosted on its own page on the subproject Web
site, and will also be indexed in a master catalog.
+ The subproject catalog will also provide a distribution mechanism.
+ The subproject will also host top-level "general" and "announcement"
mailing lists.
+ The subproject will also provide a single JAR of all stable package
releases. It may also provide a second JAR with a subset of only JDK 1.1
compatible releases. A gump of nightly builds will also be provided.
+ Committers join the library subproject in the same way they are
entered to any Jakarta subproject. Being a committer in another Jakarta
subproject is not a prerequisite, nor does it provide free entry to the
library subproject.
+ Each committer has karma for all the library packages, but is expected
to add their name to a package's status file before their first commit
to that package.
+ The library committers shall elect a committee of three committers to
provide general oversight, in the style of the Jakarta PMC.
+ New packages may be proposed to the library general list, and voted on
by all committers. To be accepted, a package proposal must receive a
positive 3/4's vote of the library committers. Packages proposed are
expected to be used by one or more ASF products.
(2)
NEW BUSINESS
The first packages on the library agenda will be:
JDBC connection pool
and
Testing Framework
Work on these packages will coincide with work on the library subproject
infrastructure.
Additional codebases to consider for the Testing Framework include
http://sourceforge.net/projects/j2eeunit - Vincent Massol
http://sourceforge.net/projects/arrowhead/ - Kevin Burton
---
Roll of Active Committers (those responding to the last poll)
Costin < cmanolache@yahoo.com >
Rodney Waldhoff < rwald@hotmail.com >
Ignacio J. Ortega < nacho@siapi.es >
Bhamidi Krishna < bhamidik@hotmail.com >
Geir Magnusson Jr. < geirm@optonline.net >
Ted Husted < news.ted@husted.com >
Federico Barbieri < scoobie@betaversion.org >
Peter Donald < donaldp@apache.org >
Ceki < cgu@qos.ch >
Morgan Delagrange < mdelagra@yahoo.com >
-Ted.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> The Taglibs model is a singleton example of something very different : there is a common thread (JSP taglib repository).
At first gloss it may seem that way, but if you look at what the tags
actually do, they seem as diverse as any packages we might propose:
JDBC, BSF, JNDI, SQL, XSL -- a person qualified to work on one of these
tags would not be automatically qualified to work on another. The tag
part is a wrapper, the meat is the same as we would see in any library
package.
-T.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> The Taglibs model is a singleton example of something very different : there is a common thread (JSP taglib repository).
At first gloss it may seem that way, but if you look at what the tags
actually do, they seem as diverse as any packages we might propose:
JDBC, BSF, JNDI, SQL, XSL -- a person qualified to work on one of these
tags would not be automatically qualified to work on another. The tag
part is a wrapper, the meat is the same as we would see in any library
package.
-T.
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I don't want to get too distracted with this thread, but I think I was
misunderstood. More inline.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > Obviously you think it does enough, Ted, or you wouldn't have written
> > it.
>
> Not really. If Costin's model had gotten the majority vote, I would have
> written that up instead. I'm perfectly capable of writing a proposal
> that I might -1 myself, if it meant many others would +1 it instead. I
> really am trying to find the model which is going to get the most
> support, regardless of whether I would support it myself.
I don't get this - I don't care personally what you are capable of doing
- you are very capable of organizing w/o your personal views
interfering.
My point overall was that structure is a departure from the jakarta
model, not simply a riff on what is already done. The Taglibs model is
a singleton example of something very different : there is a common
thread (JSP taglib repository). All the developers work in the same
space - JSP tags - and it functions as a repository of closely related
things. 'Library' is different - there is no common technology thread,
other than Java, which is kinda weak.
> > Does this model work for Jakarta? I mean, you would be a 'Jakarta
> > player', etc, etc
>
> It works for Taglibs, so we're just following suit and not creating
> anything new.
It's a different kind of project. I don't think they map.
> > If not, why not, and more importantly, where is the boundary? I imagine
> > some of what we propose could be just as 'project-like' as log4j, oro,
> > regex, etc.. and they appear to function just fine as is.
>
> I'm not sure if that's true. Log4j is fine, but I believe people have
> questioned the wisdom of having packages like RegEx, Oro, and others
> just floating around unattached.
I am not familiar with that discussion , but I would imagine that its
centered around the issue of organization of projects, rather than a
need to change the committer & governance model. Again, I am unfamiliar
with that discussion.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I don't want to get too distracted with this thread, but I think I was
misunderstood. More inline.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > Obviously you think it does enough, Ted, or you wouldn't have written
> > it.
>
> Not really. If Costin's model had gotten the majority vote, I would have
> written that up instead. I'm perfectly capable of writing a proposal
> that I might -1 myself, if it meant many others would +1 it instead. I
> really am trying to find the model which is going to get the most
> support, regardless of whether I would support it myself.
I don't get this - I don't care personally what you are capable of doing
- you are very capable of organizing w/o your personal views
interfering.
My point overall was that structure is a departure from the jakarta
model, not simply a riff on what is already done. The Taglibs model is
a singleton example of something very different : there is a common
thread (JSP taglib repository). All the developers work in the same
space - JSP tags - and it functions as a repository of closely related
things. 'Library' is different - there is no common technology thread,
other than Java, which is kinda weak.
> > Does this model work for Jakarta? I mean, you would be a 'Jakarta
> > player', etc, etc
>
> It works for Taglibs, so we're just following suit and not creating
> anything new.
It's a different kind of project. I don't think they map.
> > If not, why not, and more importantly, where is the boundary? I imagine
> > some of what we propose could be just as 'project-like' as log4j, oro,
> > regex, etc.. and they appear to function just fine as is.
>
> I'm not sure if that's true. Log4j is fine, but I believe people have
> questioned the wisdom of having packages like RegEx, Oro, and others
> just floating around unattached.
I am not familiar with that discussion , but I would imagine that its
centered around the issue of organization of projects, rather than a
need to change the committer & governance model. Again, I am unfamiliar
with that discussion.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> Obviously you think it does enough, Ted, or you wouldn't have written
> it.
Not really. If Costin's model had gotten the majority vote, I would have
written that up instead. I'm perfectly capable of writing a proposal
that I might -1 myself, if it meant many others would +1 it instead. I
really am trying to find the model which is going to get the most
support, regardless of whether I would support it myself.
> Does this model work for Jakarta? I mean, you would be a 'Jakarta
> player', etc, etc
It works for Taglibs, so we're just following suit and not creating
anything new.
> If not, why not, and more importantly, where is the boundary? I imagine
> some of what we propose could be just as 'project-like' as log4j, oro,
> regex, etc.. and they appear to function just fine as is.
I'm not sure if that's true. Log4j is fine, but I believe people have
questioned the wisdom of having packages like RegEx, Oro, and others
just floating around unattached.
> (Although doing it to avoid bothering Brian B is a good reason in itself
> :)
+1
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> Obviously you think it does enough, Ted, or you wouldn't have written
> it.
Not really. If Costin's model had gotten the majority vote, I would have
written that up instead. I'm perfectly capable of writing a proposal
that I might -1 myself, if it meant many others would +1 it instead. I
really am trying to find the model which is going to get the most
support, regardless of whether I would support it myself.
> Does this model work for Jakarta? I mean, you would be a 'Jakarta
> player', etc, etc
It works for Taglibs, so we're just following suit and not creating
anything new.
> If not, why not, and more importantly, where is the boundary? I imagine
> some of what we propose could be just as 'project-like' as log4j, oro,
> regex, etc.. and they appear to function just fine as is.
I'm not sure if that's true. Log4j is fine, but I believe people have
questioned the wisdom of having packages like RegEx, Oro, and others
just floating around unattached.
> (Although doing it to avoid bothering Brian B is a good reason in itself
> :)
+1
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > I am not sure adding to a file does much.
>
> I think it does enough, Geir. Remember, to add their name to that file
> they would have already been voted in as a committer to some other
> package. So, we already know that they are a "package player".
Obviously you think it does enough, Ted, or you wouldn't have written
it.
Does this model work for Jakarta? I mean, you would be a 'Jakarta
player', etc, etc
If so, that sounds like it would make Costin happy, and cement the
Jakarta community idea.
If not, why not, and more importantly, where is the boundary? I imagine
some of what we propose could be just as 'project-like' as log4j, oro,
regex, etc.. and they appear to function just fine as is.
Not trying to stir mud here, but this has been a fundamental point of
debate for almost the life of this discussion. From my limited exposure
to it, the Jakarta model does work, and I don't understand why we need
to improvise. If it doesn't work, then this may be a great venue to try
and improve it (and I am all for that), but I think we should identify
specific problems and target them.
(Although doing it to avoid bothering Brian B is a good reason in itself
:)
geir
> Worst case, the other committers veto an ill-considered change and
> rollback the CVS.
>
> -T.
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > I am not sure adding to a file does much.
>
> I think it does enough, Geir. Remember, to add their name to that file
> they would have already been voted in as a committer to some other
> package. So, we already know that they are a "package player".
Obviously you think it does enough, Ted, or you wouldn't have written
it.
Does this model work for Jakarta? I mean, you would be a 'Jakarta
player', etc, etc
If so, that sounds like it would make Costin happy, and cement the
Jakarta community idea.
If not, why not, and more importantly, where is the boundary? I imagine
some of what we propose could be just as 'project-like' as log4j, oro,
regex, etc.. and they appear to function just fine as is.
Not trying to stir mud here, but this has been a fundamental point of
debate for almost the life of this discussion. From my limited exposure
to it, the Jakarta model does work, and I don't understand why we need
to improvise. If it doesn't work, then this may be a great venue to try
and improve it (and I am all for that), but I think we should identify
specific problems and target them.
(Although doing it to avoid bothering Brian B is a good reason in itself
:)
geir
> Worst case, the other committers veto an ill-considered change and
> rollback the CVS.
>
> -T.
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> I am not sure adding to a file does much.
I think it does enough, Geir. Remember, to add their name to that file
they would have already been voted in as a committer to some other
package. So, we already know that they are a "package player".
Worst case, the other committers veto an ill-considered change and
rollback the CVS.
-T.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> I am not sure adding to a file does much.
I think it does enough, Geir. Remember, to add their name to that file
they would have already been voted in as a committer to some other
package. So, we already know that they are a "package player".
Worst case, the other committers veto an ill-considered change and
rollback the CVS.
-T.
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > Why? Why not let packages be the 'project' and let them run themselves?
>
> Looking over the responses to the round 1,
>
> < http://husted.com/about/jakarta/lib002.htm >
>
> it was my feeling that the consensus leaned toward the "Taglibs" model.
> Committers have access in fact, but practice discourages people form
> running in and hacking a codebase you haven't worked on. And, after all,
> we do have the CVS to help protect us from ourselves ;-).
Hm. Ok. I'll take a look. I didn't get that as the consensus at all (as
I saw a pretty much even split between library-as-mini-jakarta and
library-as-community-oriented-sourceforge, with the taglibs model there
as well a little. I will review the results so far...
> We are modifying the Tabligs model slightly, in that we are asking the
> active committers to a package list themselves in the status file.
> Again, reinforcing that working on a package is a commitment, and not a
> casual hack, and that each package is an entity unto itself.
I am not sure adding to a file does much.
> This also eliminates the overhead of a person with sufficient clearance
> (like Brian B) being bothered every time we need to upgrade someone's
> access.
Heh. Shouldn't we try to get *that* fixed?
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > Why? Why not let packages be the 'project' and let them run themselves?
>
> Looking over the responses to the round 1,
>
> < http://husted.com/about/jakarta/lib002.htm >
>
> it was my feeling that the consensus leaned toward the "Taglibs" model.
> Committers have access in fact, but practice discourages people form
> running in and hacking a codebase you haven't worked on. And, after all,
> we do have the CVS to help protect us from ourselves ;-).
Hm. Ok. I'll take a look. I didn't get that as the consensus at all (as
I saw a pretty much even split between library-as-mini-jakarta and
library-as-community-oriented-sourceforge, with the taglibs model there
as well a little. I will review the results so far...
> We are modifying the Tabligs model slightly, in that we are asking the
> active committers to a package list themselves in the status file.
> Again, reinforcing that working on a package is a commitment, and not a
> casual hack, and that each package is an entity unto itself.
I am not sure adding to a file does much.
> This also eliminates the overhead of a person with sufficient clearance
> (like Brian B) being bothered every time we need to upgrade someone's
> access.
Heh. Shouldn't we try to get *that* fixed?
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> Why? Why not let packages be the 'project' and let them run themselves?
Looking over the responses to the round 1,
< http://husted.com/about/jakarta/lib002.htm >
it was my feeling that the consensus leaned toward the "Taglibs" model.
Committers have access in fact, but practice discourages people form
running in and hacking a codebase you haven't worked on. And, after all,
we do have the CVS to help protect us from ourselves ;-).
We are modifying the Tabligs model slightly, in that we are asking the
active committers to a package list themselves in the status file.
Again, reinforcing that working on a package is a commitment, and not a
casual hack, and that each package is an entity unto itself.
This also eliminates the overhead of a person with sufficient clearance
(like Brian B) being bothered every time we need to upgrade someone's
access.
-Ted.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> Why? Why not let packages be the 'project' and let them run themselves?
Looking over the responses to the round 1,
< http://husted.com/about/jakarta/lib002.htm >
it was my feeling that the consensus leaned toward the "Taglibs" model.
Committers have access in fact, but practice discourages people form
running in and hacking a codebase you haven't worked on. And, after all,
we do have the CVS to help protect us from ourselves ;-).
We are modifying the Tabligs model slightly, in that we are asking the
active committers to a package list themselves in the status file.
Again, reinforcing that working on a package is a commitment, and not a
casual hack, and that each package is an entity unto itself.
This also eliminates the overhead of a person with sufficient clearance
(like Brian B) being bothered every time we need to upgrade someone's
access.
-Ted.
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> (1)
>
> OLD BUSINESS
>
> To finalize the first round, I'd like to get a majority vote on these
> revised points of consensus. I believe these points represent the
> consensus opinion. In the interest of unity, if possible, please provide
> a single vote on the points as a block.
>
> This poll will expire in 5 days, or when the committers on the active
> roster (below) have responded.
>
> + The primary unit of reuse and release is the package.
>
> + The package library is not a framework but a repository of codebases
> designed to be shared.
Can this be clarified or omitted? 'Shared' is obvious in open source,
isn't it?
> + Each package must have a clearly defined purpose, scope, and API -- Do
> one thing well, and keep your contracts.
>
> + Each library package is treated as a product in its own right.
>
> - - Each package has its own status file, release schedule, version
> number, QA tests, documentation, mailing list, and bug category.
I think Peter's suggestion of a general list is a good one, except can
we put some kind of mechanism to help filter?
> - - Each package must clearly specify any external dependencies,
> including any other library packages, and the earliest JDK version
> required.
>
> - - - External dependencies on optional and third-party codebases should
> be minimized.
>
> + Each package maintains a list of its active committers in its status
> file.
>
> + The packages should use a standard scheme for versioning, QA tests,
> and directory layouts, and a common format for documentation and Ant
> build files.
>
> + The packages should fit within a unified package hierarchy.
>
> + In general, packages should define an abstract interface, and provide
> one or more implementations of that interface.
I don't know if that makes sense always :
- there are some things where the interface is clear and defined
elsewhere (ex JDBC)
- multiple implementations that are indistinguishable in function and
feature add nothing but confusion for users.
This might be best left to individual packages.
> + The packages should have boring functional names. Implementations may
> choose more "exciting" designations.
?
> + Packages are encouraged to either use JavaBeans as core objects, a
> JavaBean-style API, or to provide an optional JavaBean wrapper.
>
> + External configuration files are discouraged, but if required, XML
> format files are preferred for configuration options.
>
> + The package library subproject shall be proposed as a Jakarta
> subproject.
>
> + Each package will be hosted on its own page on the subproject Web
> site, and will also be indexed in a master catalog.
>
> + The subproject catalog will also provide a distribution mechanism.
>
> + The subproject will also host top-level "general" and "announcement"
> mailing lists.
Might be good to combine these into a library-wide list. Just prefix
the subject ?
[ANNOUNCEMENT : DBCP ]
> + The subproject will also provide a single JAR of all stable package
> releases. It may also provide a second JAR with a subset of only JDK 1.1
> compatible releases. A gump of nightly builds will also be provided.
>
> + Committers join the library subproject in the same way they are
> entered to any Jakarta subproject. Being a committer in another Jakarta
> subproject is not a prerequisite, nor does it provide free entry to the
> library subproject.
But can it be noted that it helps?
> + Each committer has karma for all the library packages, but is expected
> to add their name to a package's status file before their first commit
> to that package.
Why? Why not let packages be the 'project' and let them run themselves?
> + The library committers shall elect a committee of three committers to
> provide general oversight, in the style of the Jakarta PMC.
>
> + New packages may be proposed to the library general list, and voted on
> by all committers. To be accepted, a package proposal must receive a
> positive 3/4's vote of the library committers. Packages proposed are
> expected to be used by one or more ASF products.
>
Other than the issues noted, +1
> (2)
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
+! Yay!
> and
>
> Testing Framework
+0
> Work on these packages will coincide with work on the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin Burton
>
> ---
>
> Roll of Active Committers (those responding to the last poll)
>
> Costin < cmanolache@yahoo.com >
> Rodney Waldhoff < rwald@hotmail.com >
> Ignacio J. Ortega < nacho@siapi.es >
> Bhamidi Krishna < bhamidik@hotmail.com >
> Geir Magnusson Jr. < geirm@optonline.net >
> Ted Husted < news.ted@husted.com >
> Federico Barbieri < scoobie@betaversion.org >
> Peter Donald < donaldp@apache.org >
> Ceki < cgu@qos.ch >
> Morgan Delagrange < mdelagra@yahoo.com >
>
> -Ted.
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Posted by Peter Donald <do...@apache.org>.
At 03:25 24/2/01 +0100, Vincent Massol wrote:
>Hi,
>
>I would be very happy to donate J2EEUnit to the Apache project ! ... hey, it
>already uses Ant build scripts, the Jakarta look and feel for it's web site,
>it has test suites for Tomcat, ... :)
kewl ;)
>However, when I registered it on SourceForge, I chose the first license in
>the list (I didn't know which one to choose ... :)) which happened to be the
>GPL one. Would that be a problem ? Is it possible to change a license ?
GPL is incompatable with APL but if you are sole copyright owner (or if all
contributors agree) there is no problem changing license.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
Ted Husted wrote:
> (1)
+1
> (2)
+1
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Posted by Ted Husted <ne...@husted.com>.
Vincent Massol wrote:
> However, when I registered it on SourceForge, I chose the first license in
> the list (I didn't know which one to choose ... :)) which happened to be the
> GPL one. Would that be a problem ? Is it possible to change a license ?
You still own the code, Vincent. SourgeForge is just help you distribute
it. The only person who could take issue with you changing the license
under a later release, is you ;-)
Welcome aboard!
-T.
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Posted by Ted Husted <ne...@husted.com>.
Vincent Massol wrote:
> However, when I registered it on SourceForge, I chose the first license in
> the list (I didn't know which one to choose ... :)) which happened to be the
> GPL one. Would that be a problem ? Is it possible to change a license ?
You still own the code, Vincent. SourgeForge is just help you distribute
it. The only person who could take issue with you changing the license
under a later release, is you ;-)
Welcome aboard!
-T.
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Posted by Vincent Massol <vm...@octo.fr>.
Hi,
I would be very happy to donate J2EEUnit to the Apache project ! ... hey, it
already uses Ant build scripts, the Jakarta look and feel for it's web site,
it has test suites for Tomcat, ... :)
However, when I registered it on SourceForge, I chose the first license in
the list (I didn't know which one to choose ... :)) which happened to be the
GPL one. Would that be a problem ? Is it possible to change a license ?
Thanks.
Vincent.
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
>
> and
>
> Testing Framework
>
> Work on these packages will coincide with work on the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin Burton
>
> ---
>
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Posted by Peter Donald <do...@apache.org>.
At 03:25 24/2/01 +0100, Vincent Massol wrote:
>Hi,
>
>I would be very happy to donate J2EEUnit to the Apache project ! ... hey, it
>already uses Ant build scripts, the Jakarta look and feel for it's web site,
>it has test suites for Tomcat, ... :)
kewl ;)
>However, when I registered it on SourceForge, I chose the first license in
>the list (I didn't know which one to choose ... :)) which happened to be the
>GPL one. Would that be a problem ? Is it possible to change a license ?
GPL is incompatable with APL but if you are sole copyright owner (or if all
contributors agree) there is no problem changing license.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
Ted Husted wrote:
> (1)
+1
> (2)
+1
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> (1)
>
> OLD BUSINESS
>
> To finalize the first round, I'd like to get a majority vote on these
> revised points of consensus. I believe these points represent the
> consensus opinion. In the interest of unity, if possible, please provide
> a single vote on the points as a block.
>
> This poll will expire in 5 days, or when the committers on the active
> roster (below) have responded.
>
> + The primary unit of reuse and release is the package.
>
> + The package library is not a framework but a repository of codebases
> designed to be shared.
Can this be clarified or omitted? 'Shared' is obvious in open source,
isn't it?
> + Each package must have a clearly defined purpose, scope, and API -- Do
> one thing well, and keep your contracts.
>
> + Each library package is treated as a product in its own right.
>
> - - Each package has its own status file, release schedule, version
> number, QA tests, documentation, mailing list, and bug category.
I think Peter's suggestion of a general list is a good one, except can
we put some kind of mechanism to help filter?
> - - Each package must clearly specify any external dependencies,
> including any other library packages, and the earliest JDK version
> required.
>
> - - - External dependencies on optional and third-party codebases should
> be minimized.
>
> + Each package maintains a list of its active committers in its status
> file.
>
> + The packages should use a standard scheme for versioning, QA tests,
> and directory layouts, and a common format for documentation and Ant
> build files.
>
> + The packages should fit within a unified package hierarchy.
>
> + In general, packages should define an abstract interface, and provide
> one or more implementations of that interface.
I don't know if that makes sense always :
- there are some things where the interface is clear and defined
elsewhere (ex JDBC)
- multiple implementations that are indistinguishable in function and
feature add nothing but confusion for users.
This might be best left to individual packages.
> + The packages should have boring functional names. Implementations may
> choose more "exciting" designations.
?
> + Packages are encouraged to either use JavaBeans as core objects, a
> JavaBean-style API, or to provide an optional JavaBean wrapper.
>
> + External configuration files are discouraged, but if required, XML
> format files are preferred for configuration options.
>
> + The package library subproject shall be proposed as a Jakarta
> subproject.
>
> + Each package will be hosted on its own page on the subproject Web
> site, and will also be indexed in a master catalog.
>
> + The subproject catalog will also provide a distribution mechanism.
>
> + The subproject will also host top-level "general" and "announcement"
> mailing lists.
Might be good to combine these into a library-wide list. Just prefix
the subject ?
[ANNOUNCEMENT : DBCP ]
> + The subproject will also provide a single JAR of all stable package
> releases. It may also provide a second JAR with a subset of only JDK 1.1
> compatible releases. A gump of nightly builds will also be provided.
>
> + Committers join the library subproject in the same way they are
> entered to any Jakarta subproject. Being a committer in another Jakarta
> subproject is not a prerequisite, nor does it provide free entry to the
> library subproject.
But can it be noted that it helps?
> + Each committer has karma for all the library packages, but is expected
> to add their name to a package's status file before their first commit
> to that package.
Why? Why not let packages be the 'project' and let them run themselves?
> + The library committers shall elect a committee of three committers to
> provide general oversight, in the style of the Jakarta PMC.
>
> + New packages may be proposed to the library general list, and voted on
> by all committers. To be accepted, a package proposal must receive a
> positive 3/4's vote of the library committers. Packages proposed are
> expected to be used by one or more ASF products.
>
Other than the issues noted, +1
> (2)
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
+! Yay!
> and
>
> Testing Framework
+0
> Work on these packages will coincide with work on the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin Burton
>
> ---
>
> Roll of Active Committers (those responding to the last poll)
>
> Costin < cmanolache@yahoo.com >
> Rodney Waldhoff < rwald@hotmail.com >
> Ignacio J. Ortega < nacho@siapi.es >
> Bhamidi Krishna < bhamidik@hotmail.com >
> Geir Magnusson Jr. < geirm@optonline.net >
> Ted Husted < news.ted@husted.com >
> Federico Barbieri < scoobie@betaversion.org >
> Peter Donald < donaldp@apache.org >
> Ceki < cgu@qos.ch >
> Morgan Delagrange < mdelagra@yahoo.com >
>
> -Ted.
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Posted by Vincent Massol <vm...@octo.fr>.
Hi,
I would be very happy to donate J2EEUnit to the Apache project ! ... hey, it
already uses Ant build scripts, the Jakarta look and feel for it's web site,
it has test suites for Tomcat, ... :)
However, when I registered it on SourceForge, I chose the first license in
the list (I didn't know which one to choose ... :)) which happened to be the
GPL one. Would that be a problem ? Is it possible to change a license ?
Thanks.
Vincent.
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
>
> and
>
> Testing Framework
>
> Work on these packages will coincide with work on the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin Burton
>
> ---
>
Re: [POLL] General Consensus, Round 2
Posted by Morgan Delagrange <md...@yahoo.com>.
+1. Why quibble? :)
--- Ted Husted <ne...@husted.com> wrote:
> (1)
>
> OLD BUSINESS
>
> To finalize the first round, I'd like to get a
> majority vote on these
> revised points of consensus. I believe these points
> represent the
> consensus opinion. In the interest of unity, if
> possible, please provide
> a single vote on the points as a block.
>
> This poll will expire in 5 days, or when the
> committers on the active
> roster (below) have responded.
>
> + The primary unit of reuse and release is the
> package.
>
> + The package library is not a framework but a
> repository of codebases
> designed to be shared.
>
> + Each package must have a clearly defined purpose,
> scope, and API -- Do
> one thing well, and keep your contracts.
>
> + Each library package is treated as a product in
> its own right.
>
> - - Each package has its own status file, release
> schedule, version
> number, QA tests, documentation, mailing list, and
> bug category.
>
> - - Each package must clearly specify any external
> dependencies,
> including any other library packages, and the
> earliest JDK version
> required.
>
> - - - External dependencies on optional and
> third-party codebases should
> be minimized.
>
> + Each package maintains a list of its active
> committers in its status
> file.
>
> + The packages should use a standard scheme for
> versioning, QA tests,
> and directory layouts, and a common format for
> documentation and Ant
> build files.
>
> + The packages should fit within a unified package
> hierarchy.
>
> + In general, packages should define an abstract
> interface, and provide
> one or more implementations of that interface.
>
> + The packages should have boring functional names.
> Implementations may
> choose more "exciting" designations.
>
> + Packages are encouraged to either use JavaBeans as
> core objects, a
> JavaBean-style API, or to provide an optional
> JavaBean wrapper.
>
> + External configuration files are discouraged, but
> if required, XML
> format files are preferred for configuration
> options.
>
> + The package library subproject shall be proposed
> as a Jakarta
> subproject.
>
> + Each package will be hosted on its own page on the
> subproject Web
> site, and will also be indexed in a master catalog.
>
> + The subproject catalog will also provide a
> distribution mechanism.
>
> + The subproject will also host top-level "general"
> and "announcement"
> mailing lists.
>
> + The subproject will also provide a single JAR of
> all stable package
> releases. It may also provide a second JAR with a
> subset of only JDK 1.1
> compatible releases. A gump of nightly builds will
> also be provided.
>
> + Committers join the library subproject in the same
> way they are
> entered to any Jakarta subproject. Being a committer
> in another Jakarta
> subproject is not a prerequisite, nor does it
> provide free entry to the
> library subproject.
>
> + Each committer has karma for all the library
> packages, but is expected
> to add their name to a package's status file before
> their first commit
> to that package.
>
> + The library committers shall elect a committee of
> three committers to
> provide general oversight, in the style of the
> Jakarta PMC.
>
> + New packages may be proposed to the library
> general list, and voted on
> by all committers. To be accepted, a package
> proposal must receive a
> positive 3/4's vote of the library committers.
> Packages proposed are
> expected to be used by one or more ASF products.
>
> (2)
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
>
> and
>
> Testing Framework
>
> Work on these packages will coincide with work on
> the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing
> Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent
> Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin
> Burton
>
> ---
>
> Roll of Active Committers (those responding to the
> last poll)
>
> Costin < cmanolache@yahoo.com >
> Rodney Waldhoff < rwald@hotmail.com >
> Ignacio J. Ortega < nacho@siapi.es >
> Bhamidi Krishna < bhamidik@hotmail.com >
> Geir Magnusson Jr. < geirm@optonline.net >
> Ted Husted < news.ted@husted.com >
> Federico Barbieri < scoobie@betaversion.org >
> Peter Donald < donaldp@apache.org >
> Ceki < cgu@qos.ch >
> Morgan Delagrange < mdelagra@yahoo.com >
>
> -Ted.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> >+ Committers join the library subproject in the same way they are
> >entered to any Jakarta subproject. Being a committer in another Jakarta
> >subproject is not a prerequisite, nor does it provide free entry to the
> >library subproject.
>
> unless they are moving code from the other project and are willing to act
> as caregiver and guardian ;)
How would a "caregiver and guardian" differ from a committer?
There would be a proposal to add the codebase, which could also
grandfather new committers when appropriate. So, it would be just as
easy to make them committers (which also draws them into the library
community).
-T.
Re: General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> >+ Committers join the library subproject in the same way they are
> >entered to any Jakarta subproject. Being a committer in another Jakarta
> >subproject is not a prerequisite, nor does it provide free entry to the
> >library subproject.
>
> unless they are moving code from the other project and are willing to act
> as caregiver and guardian ;)
How would a "caregiver and guardian" differ from a committer?
There would be a proposal to add the codebase, which could also
grandfather new committers when appropriate. So, it would be just as
easy to make them committers (which also draws them into the library
community).
-T.
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> cmanolache@yahoo.com wrote:
> > In any case - I hope Ted will include the 2 proposals in the final vote,
> > and I'll let the majority decide what will be the goal and rules for this
> > project.
>
> As near as I can figure we have already covered that ground, and the
> current proposal already reflects what the majority of people
> contributing to this list have decided.
I haven't seen a final vote, only 2 rounds of polling, and on each round
there were proposals to refine the polling and reword some of the
questions.
> I am making my best effort, but if you feel differently, then you might
> like to submit a proposal of your own.
Sure, but why not reuse the existing one, and add one more choice to the
poll ? :-)
Costin
Re: Library project reset
Posted by Federico Barbieri <sc...@betaversion.org>.
Morgan Delagrange wrote:
>
> Hi all,
>
> Maybe it's time for a reset here? Instead of worrying
> so much about other subprojects, why don't we focus on
> creating good stand-alone libraries? After all, we
> can't force anybody to adopt our libraries if they
> don't want to. Even if only some projects adopt our
> libraries within their framework, I'd say we've still
> made progress and provided more accessible
> distributions. Practically every Java project in
> Apache (including Struts, Avalon, and Turbine) is
> organized at the framework level, and I think it's
> time for more discrete packaging.
>
> I propose that we move forward with a dedicated set of
> committers in a fashion similar to Taglibs and not
> attempt to please every subproject. In fact, trying
> to meet everyone's needs simultaneously would probably
> lead to disaster. If this is a good idea, our
> components will converge with their frameworks in
> time.
>
> We've got lots of good ideas, such as more focused
> documentation and more minimal and explicit
> dependencies. By getting mired in the minutiae, we're
> going to lose sight of the single important goal,
> which is to produce quality stand-alone components.
>
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
>
> - Morgan
>
+1000.
I guess we have to
-pick up 2 or 3 components from the list already discussed,
-populate the CVS
-write some kind of spec (what this is supposed to do, APIs etc) from
what's already there and what can be done to make it more generic (wider
users scope)
-maybe propose these spec to an extended group of people for tuning...
During the process we will tune the "library guidelines" in terms of doc
requirements, testing etc.
as test project sounds like connection pool is a good candidate.
Fede
Re: Library project reset
Posted by cm...@yahoo.com.
> At this point, most people seemed to want to start with the JDBC
> pool. I also suggested we also work on a testing framework, along
> with the support structure.
I am interested in the last 2.
Regarding the testing framework - I don't know what will be the schedule,
tomcat3.3 needs it _now_, so development on the <gtest> will continue
inside tomcat. If we create the library CVS I'll ask tomcat-dev to move
the gtest in a library sub-project ( if the library rules will allow it
) and try to merge it with whatever testing frameworks will be
contributed.
( the <gtest> in 3.3 is just a way to
describe requests and expected responses in xml - using ant as a driver to
execute the script, and a taglib to do it from a web page. There are few
hundred tests using it, but with a small XSL we can change it to whatever
DTD will be used in the shared framework - if similar capabilities will
exist ).
Regarding the build framework - I would like to help, but after
tomcat-3.3Beta.
Costin
>
> The poll for that went up yesterday, at this point we have 4
> positive votes for that course of action, out of the ten active
> participants on this list.
>
> < http://husted.com/about/jakarta/lib003.htm >
>
> Two other participants are apparently abstaining.
>
> --
>
> "Geir Magnusson Jr." wrote:
> > Another thing is that Sam Ruby mentioned what he thought might be
> > appropriate (I can't find the post now - it was a little while ago), and
> > maybe we should review that too and take a hint :)
>
> >Sam Ruby wrote:
> > Testing and documentation requirements.
>
> There are testing frameworks breaking out all over Jakarta right now.
> One very active initiative is taking place in Struts as part of the
> upcoming beta-testing for the 1.0 release (the release plan is now
> in-vote). It's important to note that this is a contributor-based
> initiative, rather than something the "committers" started, and is now
> seeing wide support.
>
> I would suggest that anyone interesting in testing join in on the Struts
> initiative now, to see if we can use it as a base for the library
> testing requirements. I think people who haven't been involved in Struts
> will be very welcome, since they will not have preconceived notions.
> After all, we need to test this to be sure it works for newbies. The
> rest of us have been doing our own ad-hoc testing for months.
>
> As to documentation requirements for the packages, my first thoughts are
>
> (0) substantial JavaDocs (of course),
>
> (1) a standard catalog entry, outlining the package's "high concept"
> (purpose and scope), prerequisites, release history, mailing list and
> archive links, FAQ and Bugzilla links, and active committers
> ("whoWeAre"),
>
> (2) a developer's guide, that explains how to use the package in more
> detail, developer to developer,
>
> (3) a quick-start installation page for people who just want to plug it
> in,
>
> (4) obligatory quick-start FAQ,
>
> --
>
> An example of a developer's guide is here:
>
> <
> http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#package_description
> >
>
> --
>
> (1) would be the foundation for a CJAN type catalog, and might
> ultimately land in a database.
>
> --
>
> As to the Web site documentation requirements, my first thoughts are
>
> (0) Mission statement
>
> (1) General guidelines (part (1) of recent poll)
>
> (2) Catalog (collection of (1) above)
>
> (3) Primer (package creation, use, and abuse)
>
> (4) Standards - naming hierarchy, testing requirements; sample directory
> layout, build file, documentation
>
> (5) Interactive FAQ (Jyve, if it can be fixed)
>
> (6) Omnibus index to mailing lists, archives, bugzilla, and master list
> of committers
>
> --
>
> Sam's other recent "steering" comments are here:
>
> <
> http://www.mail-archive.com/library-dev%40jakarta.apache.org/msg00012.html
> >
>
> -T.
>
Re: Library project reset
Posted by cm...@yahoo.com.
> At this point, most people seemed to want to start with the JDBC
> pool. I also suggested we also work on a testing framework, along
> with the support structure.
I am interested in the last 2.
Regarding the testing framework - I don't know what will be the schedule,
tomcat3.3 needs it _now_, so development on the <gtest> will continue
inside tomcat. If we create the library CVS I'll ask tomcat-dev to move
the gtest in a library sub-project ( if the library rules will allow it
) and try to merge it with whatever testing frameworks will be
contributed.
( the <gtest> in 3.3 is just a way to
describe requests and expected responses in xml - using ant as a driver to
execute the script, and a taglib to do it from a web page. There are few
hundred tests using it, but with a small XSL we can change it to whatever
DTD will be used in the shared framework - if similar capabilities will
exist ).
Regarding the build framework - I would like to help, but after
tomcat-3.3Beta.
Costin
>
> The poll for that went up yesterday, at this point we have 4
> positive votes for that course of action, out of the ten active
> participants on this list.
>
> < http://husted.com/about/jakarta/lib003.htm >
>
> Two other participants are apparently abstaining.
>
> --
>
> "Geir Magnusson Jr." wrote:
> > Another thing is that Sam Ruby mentioned what he thought might be
> > appropriate (I can't find the post now - it was a little while ago), and
> > maybe we should review that too and take a hint :)
>
> >Sam Ruby wrote:
> > Testing and documentation requirements.
>
> There are testing frameworks breaking out all over Jakarta right now.
> One very active initiative is taking place in Struts as part of the
> upcoming beta-testing for the 1.0 release (the release plan is now
> in-vote). It's important to note that this is a contributor-based
> initiative, rather than something the "committers" started, and is now
> seeing wide support.
>
> I would suggest that anyone interesting in testing join in on the Struts
> initiative now, to see if we can use it as a base for the library
> testing requirements. I think people who haven't been involved in Struts
> will be very welcome, since they will not have preconceived notions.
> After all, we need to test this to be sure it works for newbies. The
> rest of us have been doing our own ad-hoc testing for months.
>
> As to documentation requirements for the packages, my first thoughts are
>
> (0) substantial JavaDocs (of course),
>
> (1) a standard catalog entry, outlining the package's "high concept"
> (purpose and scope), prerequisites, release history, mailing list and
> archive links, FAQ and Bugzilla links, and active committers
> ("whoWeAre"),
>
> (2) a developer's guide, that explains how to use the package in more
> detail, developer to developer,
>
> (3) a quick-start installation page for people who just want to plug it
> in,
>
> (4) obligatory quick-start FAQ,
>
> --
>
> An example of a developer's guide is here:
>
> <
> http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#package_description
> >
>
> --
>
> (1) would be the foundation for a CJAN type catalog, and might
> ultimately land in a database.
>
> --
>
> As to the Web site documentation requirements, my first thoughts are
>
> (0) Mission statement
>
> (1) General guidelines (part (1) of recent poll)
>
> (2) Catalog (collection of (1) above)
>
> (3) Primer (package creation, use, and abuse)
>
> (4) Standards - naming hierarchy, testing requirements; sample directory
> layout, build file, documentation
>
> (5) Interactive FAQ (Jyve, if it can be fixed)
>
> (6) Omnibus index to mailing lists, archives, bugzilla, and master list
> of committers
>
> --
>
> Sam's other recent "steering" comments are here:
>
> <
> http://www.mail-archive.com/library-dev%40jakarta.apache.org/msg00012.html
> >
>
> -T.
>
Re: Library project reset
Posted by Ted Husted <ne...@husted.com>.
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off?
At this point, most people seemed to want to start with the JDBC
pool. I also suggested we also work on a testing framework, along
with the support structure.
The poll for that went up yesterday, at this point we have 4
positive votes for that course of action, out of the ten active
participants on this list.
< http://husted.com/about/jakarta/lib003.htm >
Two other participants are apparently abstaining.
--
"Geir Magnusson Jr." wrote:
> Another thing is that Sam Ruby mentioned what he thought might be
> appropriate (I can't find the post now - it was a little while ago), and
> maybe we should review that too and take a hint :)
>Sam Ruby wrote:
> Testing and documentation requirements.
There are testing frameworks breaking out all over Jakarta right now.
One very active initiative is taking place in Struts as part of the
upcoming beta-testing for the 1.0 release (the release plan is now
in-vote). It's important to note that this is a contributor-based
initiative, rather than something the "committers" started, and is now
seeing wide support.
I would suggest that anyone interesting in testing join in on the Struts
initiative now, to see if we can use it as a base for the library
testing requirements. I think people who haven't been involved in Struts
will be very welcome, since they will not have preconceived notions.
After all, we need to test this to be sure it works for newbies. The
rest of us have been doing our own ad-hoc testing for months.
As to documentation requirements for the packages, my first thoughts are
(0) substantial JavaDocs (of course),
(1) a standard catalog entry, outlining the package's "high concept"
(purpose and scope), prerequisites, release history, mailing list and
archive links, FAQ and Bugzilla links, and active committers
("whoWeAre"),
(2) a developer's guide, that explains how to use the package in more
detail, developer to developer,
(3) a quick-start installation page for people who just want to plug it
in,
(4) obligatory quick-start FAQ,
--
An example of a developer's guide is here:
<
http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#package_description
>
--
(1) would be the foundation for a CJAN type catalog, and might
ultimately land in a database.
--
As to the Web site documentation requirements, my first thoughts are
(0) Mission statement
(1) General guidelines (part (1) of recent poll)
(2) Catalog (collection of (1) above)
(3) Primer (package creation, use, and abuse)
(4) Standards - naming hierarchy, testing requirements; sample directory
layout, build file, documentation
(5) Interactive FAQ (Jyve, if it can be fixed)
(6) Omnibus index to mailing lists, archives, bugzilla, and master list
of committers
--
Sam's other recent "steering" comments are here:
<
http://www.mail-archive.com/library-dev%40jakarta.apache.org/msg00012.html
>
-T.
Re: Library project reset
Posted by Ted Husted <ne...@husted.com>.
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off?
At this point, most people seemed to want to start with the JDBC
pool. I also suggested we also work on a testing framework, along
with the support structure.
The poll for that went up yesterday, at this point we have 4
positive votes for that course of action, out of the ten active
participants on this list.
< http://husted.com/about/jakarta/lib003.htm >
Two other participants are apparently abstaining.
--
"Geir Magnusson Jr." wrote:
> Another thing is that Sam Ruby mentioned what he thought might be
> appropriate (I can't find the post now - it was a little while ago), and
> maybe we should review that too and take a hint :)
>Sam Ruby wrote:
> Testing and documentation requirements.
There are testing frameworks breaking out all over Jakarta right now.
One very active initiative is taking place in Struts as part of the
upcoming beta-testing for the 1.0 release (the release plan is now
in-vote). It's important to note that this is a contributor-based
initiative, rather than something the "committers" started, and is now
seeing wide support.
I would suggest that anyone interesting in testing join in on the Struts
initiative now, to see if we can use it as a base for the library
testing requirements. I think people who haven't been involved in Struts
will be very welcome, since they will not have preconceived notions.
After all, we need to test this to be sure it works for newbies. The
rest of us have been doing our own ad-hoc testing for months.
As to documentation requirements for the packages, my first thoughts are
(0) substantial JavaDocs (of course),
(1) a standard catalog entry, outlining the package's "high concept"
(purpose and scope), prerequisites, release history, mailing list and
archive links, FAQ and Bugzilla links, and active committers
("whoWeAre"),
(2) a developer's guide, that explains how to use the package in more
detail, developer to developer,
(3) a quick-start installation page for people who just want to plug it
in,
(4) obligatory quick-start FAQ,
--
An example of a developer's guide is here:
<
http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#package_description
>
--
(1) would be the foundation for a CJAN type catalog, and might
ultimately land in a database.
--
As to the Web site documentation requirements, my first thoughts are
(0) Mission statement
(1) General guidelines (part (1) of recent poll)
(2) Catalog (collection of (1) above)
(3) Primer (package creation, use, and abuse)
(4) Standards - naming hierarchy, testing requirements; sample directory
layout, build file, documentation
(5) Interactive FAQ (Jyve, if it can be fixed)
(6) Omnibus index to mailing lists, archives, bugzilla, and master list
of committers
--
Sam's other recent "steering" comments are here:
<
http://www.mail-archive.com/library-dev%40jakarta.apache.org/msg00012.html
>
-T.
Re: Library project reset
Posted by Federico Barbieri <sc...@betaversion.org>.
Morgan Delagrange wrote:
>
> Hi all,
>
> Maybe it's time for a reset here? Instead of worrying
> so much about other subprojects, why don't we focus on
> creating good stand-alone libraries? After all, we
> can't force anybody to adopt our libraries if they
> don't want to. Even if only some projects adopt our
> libraries within their framework, I'd say we've still
> made progress and provided more accessible
> distributions. Practically every Java project in
> Apache (including Struts, Avalon, and Turbine) is
> organized at the framework level, and I think it's
> time for more discrete packaging.
>
> I propose that we move forward with a dedicated set of
> committers in a fashion similar to Taglibs and not
> attempt to please every subproject. In fact, trying
> to meet everyone's needs simultaneously would probably
> lead to disaster. If this is a good idea, our
> components will converge with their frameworks in
> time.
>
> We've got lots of good ideas, such as more focused
> documentation and more minimal and explicit
> dependencies. By getting mired in the minutiae, we're
> going to lose sight of the single important goal,
> which is to produce quality stand-alone components.
>
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
>
> - Morgan
>
+1000.
I guess we have to
-pick up 2 or 3 components from the list already discussed,
-populate the CVS
-write some kind of spec (what this is supposed to do, APIs etc) from
what's already there and what can be done to make it more generic (wider
users scope)
-maybe propose these spec to an extended group of people for tuning...
During the process we will tune the "library guidelines" in terms of doc
requirements, testing etc.
as test project sounds like connection pool is a good candidate.
Fede
Re: Library project reset
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
Right. We can do more shouting later when we have something to shout
about.
Another thing is that Sam Ruby mentioned what he thought might be
appropriate (I can't find the post now - it was a little while ago), and
maybe we should review that too and take a hint :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Library project reset
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
Right. We can do more shouting later when we have something to shout
about.
Another thing is that Sam Ruby mentioned what he thought might be
appropriate (I can't find the post now - it was a little while ago), and
maybe we should review that too and take a hint :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Library project reset
Posted by Morgan Delagrange <md...@yahoo.com>.
Hi all,
Maybe it's time for a reset here? Instead of worrying
so much about other subprojects, why don't we focus on
creating good stand-alone libraries? After all, we
can't force anybody to adopt our libraries if they
don't want to. Even if only some projects adopt our
libraries within their framework, I'd say we've still
made progress and provided more accessible
distributions. Practically every Java project in
Apache (including Struts, Avalon, and Turbine) is
organized at the framework level, and I think it's
time for more discrete packaging.
I propose that we move forward with a dedicated set of
committers in a fashion similar to Taglibs and not
attempt to please every subproject. In fact, trying
to meet everyone's needs simultaneously would probably
lead to disaster. If this is a good idea, our
components will converge with their frameworks in
time.
We've got lots of good ideas, such as more focused
documentation and more minimal and explicit
dependencies. By getting mired in the minutiae, we're
going to lose sight of the single important goal,
which is to produce quality stand-alone components.
How about we pick one or two components, gather some
likely starting candidates for a baseline, and have a
cook-off? Really, if we don't work in a small group,
it's going to be group-vs.-group-vs.-group,
my-framework-is-better-than-your-framework, and
nothing will be accomplished.
- Morgan
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Library project reset
Posted by Morgan Delagrange <md...@yahoo.com>.
Hi all,
Maybe it's time for a reset here? Instead of worrying
so much about other subprojects, why don't we focus on
creating good stand-alone libraries? After all, we
can't force anybody to adopt our libraries if they
don't want to. Even if only some projects adopt our
libraries within their framework, I'd say we've still
made progress and provided more accessible
distributions. Practically every Java project in
Apache (including Struts, Avalon, and Turbine) is
organized at the framework level, and I think it's
time for more discrete packaging.
I propose that we move forward with a dedicated set of
committers in a fashion similar to Taglibs and not
attempt to please every subproject. In fact, trying
to meet everyone's needs simultaneously would probably
lead to disaster. If this is a good idea, our
components will converge with their frameworks in
time.
We've got lots of good ideas, such as more focused
documentation and more minimal and explicit
dependencies. By getting mired in the minutiae, we're
going to lose sight of the single important goal,
which is to produce quality stand-alone components.
How about we pick one or two components, gather some
likely starting candidates for a baseline, and have a
cook-off? Really, if we don't work in a small group,
it's going to be group-vs.-group-vs.-group,
my-framework-is-better-than-your-framework, and
nothing will be accomplished.
- Morgan
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> That's right. But then with your model of user-gets-auto-veto, would it
> be right that Velocity, which for example would just use the code and
> not participate in the development, can basically interfere with the
> development evolution of the component that Tomcat is dependent upon?
Yes. Sharing a component and using a shared component means you agree to
let others have a say in that component. If both velocity and tomcat are
using a component, both project should be able to vote on it's evolution.
BTW, I don't agree with this "user" stuff - we are talking about projects
using a shared component - it's more than just an user, and it probably
involves active development ( at least on the project side ). If the
component is too good or too boring - probably it will not matter.
But that's a secondary issue - the important question is if a project can
vote on sharing a component and place it in the library without aproval
from the existing components in the library, even if a similar component
exists already.
> > 1. We either let each project decide on it's own to share / use, and make
> > it as easy as possible to do so.
>
> All projects now have the ability to share in a way thats accessable to
> others. Some choose not to, and there are good reasons. There is
> defacto sharing, as the code is open to all.
I don't think we have real sharing - some projects may choose to write
component-like code and other can use it, but I don't think that's enough.
And the current model doens't seem to work - as you can see there is a lot
of duplication and very little reuse. Why ? Because there are a lot of
bariers in working with the code developed in other project, and the
components are not designed and perceived as shared.
> The problem is that *right now* no one wants to own and care for some of
> the smaller pieces, like a DB connection pool.
It seems the reverse is true - each project is duplicating the smaller
pieces ( by creating its own implementation ).
> Why is that?
IMHO - because we don't have a library and a mechanism for projects to
"outsource" general purpose code that is not essential to their
functionality.
By placing a component in the library a project will get more eyes and
ideas, but in order for that to work it needs to do something that is
benefical for other projects. And will be able to stay focused to it's
main goal. But that can't happen if they are not willing to share control
with other projects involved.
That's my theory - and I spent enough time arguing on this, I have too
much work to do - I'll vote when the final proposal is made, and if this
is the project I need I'll start fighting to get tomcat share and use
common code. If not - I'll wait for the right project.
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> That's right. But then with your model of user-gets-auto-veto, would it
> be right that Velocity, which for example would just use the code and
> not participate in the development, can basically interfere with the
> development evolution of the component that Tomcat is dependent upon?
Yes. Sharing a component and using a shared component means you agree to
let others have a say in that component. If both velocity and tomcat are
using a component, both project should be able to vote on it's evolution.
BTW, I don't agree with this "user" stuff - we are talking about projects
using a shared component - it's more than just an user, and it probably
involves active development ( at least on the project side ). If the
component is too good or too boring - probably it will not matter.
But that's a secondary issue - the important question is if a project can
vote on sharing a component and place it in the library without aproval
from the existing components in the library, even if a similar component
exists already.
> > 1. We either let each project decide on it's own to share / use, and make
> > it as easy as possible to do so.
>
> All projects now have the ability to share in a way thats accessable to
> others. Some choose not to, and there are good reasons. There is
> defacto sharing, as the code is open to all.
I don't think we have real sharing - some projects may choose to write
component-like code and other can use it, but I don't think that's enough.
And the current model doens't seem to work - as you can see there is a lot
of duplication and very little reuse. Why ? Because there are a lot of
bariers in working with the code developed in other project, and the
components are not designed and perceived as shared.
> The problem is that *right now* no one wants to own and care for some of
> the smaller pieces, like a DB connection pool.
It seems the reverse is true - each project is duplicating the smaller
pieces ( by creating its own implementation ).
> Why is that?
IMHO - because we don't have a library and a mechanism for projects to
"outsource" general purpose code that is not essential to their
functionality.
By placing a component in the library a project will get more eyes and
ideas, but in order for that to work it needs to do something that is
benefical for other projects. And will be able to stay focused to it's
main goal. But that can't happen if they are not willing to share control
with other projects involved.
That's my theory - and I spent enough time arguing on this, I have too
much work to do - I'll vote when the final proposal is made, and if this
is the project I need I'll start fighting to get tomcat share and use
common code. If not - I'll wait for the right project.
Costin
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > >What makes you think that whatever DBPool you choose will be better ? And
> > >what makes you think that a project will be happy to replace some code
> > >they developed and serve their purpose with something they have no control
> > >over ?
> >
> > I assumed there was some turbine developers on this list ;) If not is there
> > some struts developers ? It may be good for people to say where they will
> > be able to help migrate in code. I am involved with both Aalon and Ant and
> > will be happy to do what is appropriate to facilitate sharing between these
> > two and this library project.
>
> My point was that the decision should come from a project that wants to
> share a piece of code ( or use a shared component ) - and they shouldn't
> have to be "aproved" by a library comitee.
I don't understand the model you have. No one is forced to do anything.
> I'm a tomcat commiter, but I can't decide on my own to take a piece of
> tomcat, change it, put it in the library and then change
> tomcat to use the library. It should be a decision on tomcat-dev, and the
> people who vote +1 on it and are doing the work of refactoring the
> component for inclusion should be able to maintain in the new repository.
That's right. But then with your model of user-gets-auto-veto, would it
be right that Velocity, which for example would just use the code and
not participate in the development, can basically interfere with the
development evolution of the component that Tomcat is dependent upon?
I agree that only tomcat-dev can decide on how to change tomcat to use
components in the library. And if there is a piece of tomcat that would
be a good candidate, then by all means someone should organize a bit and
propose adding a new component (which I assume would be waved right in
if it was a new addition), or explaining why the existing one doesn't
work [and then working with the existing group to decide if you add
another, or work on the first to fit...]
[SNIP]
> It's very simple:
>
> 1. We either let each project decide on it's own to share / use, and make
> it as easy as possible to do so.
All projects now have the ability to share in a way thats accessable to
others. Some choose not to, and there are good reasons. There is
defacto sharing, as the code is open to all.
The problem is that *right now* no one wants to own and care for some of
the smaller pieces, like a DB connection pool.
Why is that?
> or
>
> 2. Grab code from projects (selecting by vote which component) or create
> new components, with the goal of creating server-side components for
> projects.
> I don't see any reason (2) can't be done in avalon - after all the goal of
> avalon is exactly that.
>
> I also think there is a need for (1), and if the project we are discussing
> now (the library ) is not doing that, probably we need another project.
>
> Costin
>
>
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > >What makes you think that whatever DBPool you choose will be better ? And
> > >what makes you think that a project will be happy to replace some code
> > >they developed and serve their purpose with something they have no control
> > >over ?
> >
> > I assumed there was some turbine developers on this list ;) If not is there
> > some struts developers ? It may be good for people to say where they will
> > be able to help migrate in code. I am involved with both Aalon and Ant and
> > will be happy to do what is appropriate to facilitate sharing between these
> > two and this library project.
>
> My point was that the decision should come from a project that wants to
> share a piece of code ( or use a shared component ) - and they shouldn't
> have to be "aproved" by a library comitee.
I don't understand the model you have. No one is forced to do anything.
> I'm a tomcat commiter, but I can't decide on my own to take a piece of
> tomcat, change it, put it in the library and then change
> tomcat to use the library. It should be a decision on tomcat-dev, and the
> people who vote +1 on it and are doing the work of refactoring the
> component for inclusion should be able to maintain in the new repository.
That's right. But then with your model of user-gets-auto-veto, would it
be right that Velocity, which for example would just use the code and
not participate in the development, can basically interfere with the
development evolution of the component that Tomcat is dependent upon?
I agree that only tomcat-dev can decide on how to change tomcat to use
components in the library. And if there is a piece of tomcat that would
be a good candidate, then by all means someone should organize a bit and
propose adding a new component (which I assume would be waved right in
if it was a new addition), or explaining why the existing one doesn't
work [and then working with the existing group to decide if you add
another, or work on the first to fit...]
[SNIP]
> It's very simple:
>
> 1. We either let each project decide on it's own to share / use, and make
> it as easy as possible to do so.
All projects now have the ability to share in a way thats accessable to
others. Some choose not to, and there are good reasons. There is
defacto sharing, as the code is open to all.
The problem is that *right now* no one wants to own and care for some of
the smaller pieces, like a DB connection pool.
Why is that?
> or
>
> 2. Grab code from projects (selecting by vote which component) or create
> new components, with the goal of creating server-side components for
> projects.
> I don't see any reason (2) can't be done in avalon - after all the goal of
> avalon is exactly that.
>
> I also think there is a need for (1), and if the project we are discussing
> now (the library ) is not doing that, probably we need another project.
>
> Costin
>
>
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> >What makes you think that whatever DBPool you choose will be better ? And
> >what makes you think that a project will be happy to replace some code
> >they developed and serve their purpose with something they have no control
> >over ?
>
> I assumed there was some turbine developers on this list ;) If not is there
> some struts developers ? It may be good for people to say where they will
> be able to help migrate in code. I am involved with both Aalon and Ant and
> will be happy to do what is appropriate to facilitate sharing between these
> two and this library project.
My point was that the decision should come from a project that wants to
share a piece of code ( or use a shared component ) - and they shouldn't
have to be "aproved" by a library comitee.
I'm a tomcat commiter, but I can't decide on my own to take a piece of
tomcat, change it, put it in the library and then change
tomcat to use the library. It should be a decision on tomcat-dev, and the
people who vote +1 on it and are doing the work of refactoring the
component for inclusion should be able to maintain in the new repository.
If DBPool from turbine is to be included I hope it'll be a vote on
turbine-dev, some turbine developers ( who know the component the best
) will volunteer to help and do the needed refactoring ( I don't think
that someone from outside can do a better job than the original
maintainers of the code ).
It's very simple:
1. We either let each project decide on it's own to share / use, and make
it as easy as possible to do so.
or
2. Grab code from projects (selecting by vote which component) or create
new components, with the goal of creating server-side components for
projects.
I don't see any reason (2) can't be done in avalon - after all the goal of
avalon is exactly that.
I also think there is a need for (1), and if the project we are discussing
now (the library ) is not doing that, probably we need another project.
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> >What makes you think that whatever DBPool you choose will be better ? And
> >what makes you think that a project will be happy to replace some code
> >they developed and serve their purpose with something they have no control
> >over ?
>
> I assumed there was some turbine developers on this list ;) If not is there
> some struts developers ? It may be good for people to say where they will
> be able to help migrate in code. I am involved with both Aalon and Ant and
> will be happy to do what is appropriate to facilitate sharing between these
> two and this library project.
My point was that the decision should come from a project that wants to
share a piece of code ( or use a shared component ) - and they shouldn't
have to be "aproved" by a library comitee.
I'm a tomcat commiter, but I can't decide on my own to take a piece of
tomcat, change it, put it in the library and then change
tomcat to use the library. It should be a decision on tomcat-dev, and the
people who vote +1 on it and are doing the work of refactoring the
component for inclusion should be able to maintain in the new repository.
If DBPool from turbine is to be included I hope it'll be a vote on
turbine-dev, some turbine developers ( who know the component the best
) will volunteer to help and do the needed refactoring ( I don't think
that someone from outside can do a better job than the original
maintainers of the code ).
It's very simple:
1. We either let each project decide on it's own to share / use, and make
it as easy as possible to do so.
or
2. Grab code from projects (selecting by vote which component) or create
new components, with the goal of creating server-side components for
projects.
I don't see any reason (2) can't be done in avalon - after all the goal of
avalon is exactly that.
I also think there is a need for (1), and if the project we are discussing
now (the library ) is not doing that, probably we need another project.
Costin
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 06:14 22/2/01 -0800, cmanolache@yahoo.com wrote:
>And why not letting the original authors of a component decide for
>themself what to do with a component ? And why not let turbine decide if
>they want to share the component and how to do it ?
>
>What makes you think that whatever DBPool you choose will be better ? And
>what makes you think that a project will be happy to replace some code
>they developed and serve their purpose with something they have no control
>over ?
I assumed there was some turbine developers on this list ;) If not is there
some struts developers ? It may be good for people to say where they will
be able to help migrate in code. I am involved with both Aalon and Ant and
will be happy to do what is appropriate to facilitate sharing between these
two and this library project.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 06:14 22/2/01 -0800, cmanolache@yahoo.com wrote:
>And why not letting the original authors of a component decide for
>themself what to do with a component ? And why not let turbine decide if
>they want to share the component and how to do it ?
>
>What makes you think that whatever DBPool you choose will be better ? And
>what makes you think that a project will be happy to replace some code
>they developed and serve their purpose with something they have no control
>over ?
I assumed there was some turbine developers on this list ;) If not is there
some struts developers ? It may be good for people to say where they will
be able to help migrate in code. I am involved with both Aalon and Ant and
will be happy to do what is appropriate to facilitate sharing between these
two and this library project.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 10:42 22/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>
>> A few days ago I indicated the 4 paths I saw were
>>
>> 1. component repository (ie ToolForge+CJAN)
>> 2. vetted/tested/approved components (ie Avalon+CJAN)
>> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>> 4. gathering
>>
>> (3) is easily doable within current apache model. I believe Costin wants to
>> work in (1) and Avalon covers enough of (2) that I don't see it worth
>> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
>> which I am -1 on at the moment.
>
>Except that Avalon doesn't appear to be a 'catalog' of separate,
>independant components that are individually documented, buildable,
>etc...
you can always enhance the Avalon project in such a manner ;) Done well
enough it could be a great precursor to CJAN ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 10:42 22/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>
>> A few days ago I indicated the 4 paths I saw were
>>
>> 1. component repository (ie ToolForge+CJAN)
>> 2. vetted/tested/approved components (ie Avalon+CJAN)
>> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>> 4. gathering
>>
>> (3) is easily doable within current apache model. I believe Costin wants to
>> work in (1) and Avalon covers enough of (2) that I don't see it worth
>> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
>> which I am -1 on at the moment.
>
>Except that Avalon doesn't appear to be a 'catalog' of separate,
>independant components that are individually documented, buildable,
>etc...
you can always enhance the Avalon project in such a manner ;) Done well
enough it could be a great precursor to CJAN ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
> A few days ago I indicated the 4 paths I saw were
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
> 4. gathering
>
> (3) is easily doable within current apache model. I believe Costin wants to
> work in (1) and Avalon covers enough of (2) that I don't see it worth
> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
> which I am -1 on at the moment.
Except that Avalon doesn't appear to be a 'catalog' of separate,
independant components that are individually documented, buildable,
etc... That's what I have in mind for (2), which I am +1 on. I am also
+0 on (1) [as time is precious these days, and I want to get a *great*
DBCP developed and componentized - there is movement afoot in
Turbine-land for a JDBC compliant component, and Struts is pretty much
there...], +0 on (3) [same reason - no time - but a good idea], and I
don't know what (4) is...
Can we change the name of this list to 'catalog-dev' ? :)
> >From what I gathered our plan of attack was (1). ie Our first module would
> be the DBPool. We would extract it from somewhere (say turbine) refactor
> it. Then push it back into turbine with a wrapper that integrates it into
> the turbine framework. We would then try to integrate it into struts and
> anyone else that uses DB pools. Then we would pick another component and do
> the same. Have I got this correct/wrong?
It might be easier to start with what Struts has is you are in the mood
for JDBC compliant interfaces, but there is lots of discussion going on
in Turbine-land about this. It's a great time to do this...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
> A few days ago I indicated the 4 paths I saw were
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
> 4. gathering
>
> (3) is easily doable within current apache model. I believe Costin wants to
> work in (1) and Avalon covers enough of (2) that I don't see it worth
> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
> which I am -1 on at the moment.
Except that Avalon doesn't appear to be a 'catalog' of separate,
independant components that are individually documented, buildable,
etc... That's what I have in mind for (2), which I am +1 on. I am also
+0 on (1) [as time is precious these days, and I want to get a *great*
DBCP developed and componentized - there is movement afoot in
Turbine-land for a JDBC compliant component, and Struts is pretty much
there...], +0 on (3) [same reason - no time - but a good idea], and I
don't know what (4) is...
Can we change the name of this list to 'catalog-dev' ? :)
> >From what I gathered our plan of attack was (1). ie Our first module would
> be the DBPool. We would extract it from somewhere (say turbine) refactor
> it. Then push it back into turbine with a wrapper that integrates it into
> the turbine framework. We would then try to integrate it into struts and
> anyone else that uses DB pools. Then we would pick another component and do
> the same. Have I got this correct/wrong?
It might be easier to start with what Struts has is you are in the mood
for JDBC compliant interfaces, but there is lots of discussion going on
in Turbine-land about this. It's a great time to do this...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> I think this item kinda hits the nail on the head as far as most of the
> disagreement going on right now. So perhaps nailing down what the specific
> "Goal" or perhaps "Range of goals" are could clarify this? Here is my
> somewhat vague understanding of the goals of this project:
>
> "To create high quality components or tools that are commonly used by or
> alongside other products of the jakarta project as a whole."
My understanding of the goal is:
"To help jakarta projects to share code and development of
commonly used components, leading to a high quality component repository"
It's probably the same thing - but from a different perspective. I think
essential to the repository success is getting the existing communities to
share and cooperate. From your form I get the message that creating the
components and the code is essential.
> It seems that the discussion is quickly becoming a battle of the specific
> visions of how to reuse. I don't see how that moves us any closer to what
> I understand the goal to be, but that could just be me misunderstanding
> the goal. Any thoughts?
Or it may be my understanding - or the goal can be somewhere in the
middle.
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> I think this item kinda hits the nail on the head as far as most of the
> disagreement going on right now. So perhaps nailing down what the specific
> "Goal" or perhaps "Range of goals" are could clarify this? Here is my
> somewhat vague understanding of the goals of this project:
>
> "To create high quality components or tools that are commonly used by or
> alongside other products of the jakarta project as a whole."
My understanding of the goal is:
"To help jakarta projects to share code and development of
commonly used components, leading to a high quality component repository"
It's probably the same thing - but from a different perspective. I think
essential to the repository success is getting the existing communities to
share and cooperate. From your form I get the message that creating the
components and the code is essential.
> It seems that the discussion is quickly becoming a battle of the specific
> visions of how to reuse. I don't see how that moves us any closer to what
> I understand the goal to be, but that could just be me misunderstanding
> the goal. Any thoughts?
Or it may be my understanding - or the goal can be somewhere in the
middle.
Costin
Re: [POLL] General Consensus, Round 2
Posted by David Weinrich <dw...@home.com>.
On Thu, 22 Feb 2001 cmanolache@yahoo.com wrote:
>
> I was assuming the goal of the project is to have jakarta projects share
> code - not to take common code without it's community and create another
> project out of it.
>
> Costin
>
>
I think this item kinda hits the nail on the head as far as most of the
disagreement going on right now. So perhaps nailing down what the specific
"Goal" or perhaps "Range of goals" are could clarify this? Here is my
somewhat vague understanding of the goals of this project:
"To create high quality components or tools that are commonly used by or
alongside other products of the jakarta project as a whole."
Now, in this case create is fairly open. This can mean:
* Having someone from a jakarta project donating the code as a starting
point and the interested committers from within jakarta get together and
get the code molded into the vision of a well-specified tool that fits a
general need, with wrappers to fit that generalized tool back into the
other products in jakarta
OR
* Having the interested parties specify an API for the 'ideal' shared
tool and looking through the existing code in jakarta...
OR
...insert many other options.
It seems that the discussion is quickly becoming a battle of the specific
visions of how to reuse. I don't see how that moves us any closer to what
I understand the goal to be, but that could just be me misunderstanding
the goal. Any thoughts?
David
Re: [POLL] General Consensus, Round 2
Posted by David Weinrich <dw...@home.com>.
On Thu, 22 Feb 2001 cmanolache@yahoo.com wrote:
>
> I was assuming the goal of the project is to have jakarta projects share
> code - not to take common code without it's community and create another
> project out of it.
>
> Costin
>
>
I think this item kinda hits the nail on the head as far as most of the
disagreement going on right now. So perhaps nailing down what the specific
"Goal" or perhaps "Range of goals" are could clarify this? Here is my
somewhat vague understanding of the goals of this project:
"To create high quality components or tools that are commonly used by or
alongside other products of the jakarta project as a whole."
Now, in this case create is fairly open. This can mean:
* Having someone from a jakarta project donating the code as a starting
point and the interested committers from within jakarta get together and
get the code molded into the vision of a well-specified tool that fits a
general need, with wrappers to fit that generalized tool back into the
other products in jakarta
OR
* Having the interested parties specify an API for the 'ideal' shared
tool and looking through the existing code in jakarta...
OR
...insert many other options.
It seems that the discussion is quickly becoming a battle of the specific
visions of how to reuse. I don't see how that moves us any closer to what
I understand the goal to be, but that could just be me misunderstanding
the goal. Any thoughts?
David
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> Why not add a third (3) Repository, lead by Costin, in the model of
> all-inclusive, everyone gets a vote, add code and you're a committer,
> aka 'JakartaForge'. That fits into the model, as a subproject, like a
> regular Jakarta project, has reasonable control over it's destiny and
> rules, so if anything goes, anything goes. It will certainly be a good
> test to see how that community model works compared to the Jakarta
> community model.
That's not what I'm proposing - if a project wants to share a component (
or develop a new component that is not specific to that project, but of
general interest ) it can use the common "repository" as long as it
accepts the rules:
1. follow the general guidelines ( we all agreed on )
2. Share the development with other projects, if other projects are
interested in using that component. That rules is supposed to encourage
other projects to use the component, knowing they have an official vote.
If a project doesn't want to share a component with other projects ( I'm
talking about control and development ) - then it shoulnd't use the
repository, but keep it private to that project.
( there are different degrees on the level of control sharing )
> > And why not letting the original authors of a component decide for
> > themself what to do with a component ? And why not let turbine decide if
> > they want to share the component and how to do it ?
>
> They do - they released the code under APL, sharing with everyone. But
> they are currently choosing to keep it integrated in Turbine,
> subordinate to the needs of turbine, and not documented as a separable
> unit. That is the choice *they* are making *today*.
And you want to fork the code and create your own version ? That's not
very nice. Maybe other project have a pool and they want to share. And
maybe turbine will see the benefits of sharing and decide to participate
in the library.
A lot of people claim the community is more important than the code - if
you can't get the community behind a FooPool, the code is not that
important.
> > What makes you think that whatever DBPool you choose will be better ? And
> > what makes you think that a project will be happy to replace some code
> > they developed and serve their purpose with something they have no control
> > over ?
>
> Why do you think that projects will be *required* to replace their code
> with the so-called 'library' code?
I was assuming the goal of the project is to have jakarta projects share
code - not to take common code without it's community and create another
project out of it.
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> Why not add a third (3) Repository, lead by Costin, in the model of
> all-inclusive, everyone gets a vote, add code and you're a committer,
> aka 'JakartaForge'. That fits into the model, as a subproject, like a
> regular Jakarta project, has reasonable control over it's destiny and
> rules, so if anything goes, anything goes. It will certainly be a good
> test to see how that community model works compared to the Jakarta
> community model.
That's not what I'm proposing - if a project wants to share a component (
or develop a new component that is not specific to that project, but of
general interest ) it can use the common "repository" as long as it
accepts the rules:
1. follow the general guidelines ( we all agreed on )
2. Share the development with other projects, if other projects are
interested in using that component. That rules is supposed to encourage
other projects to use the component, knowing they have an official vote.
If a project doesn't want to share a component with other projects ( I'm
talking about control and development ) - then it shoulnd't use the
repository, but keep it private to that project.
( there are different degrees on the level of control sharing )
> > And why not letting the original authors of a component decide for
> > themself what to do with a component ? And why not let turbine decide if
> > they want to share the component and how to do it ?
>
> They do - they released the code under APL, sharing with everyone. But
> they are currently choosing to keep it integrated in Turbine,
> subordinate to the needs of turbine, and not documented as a separable
> unit. That is the choice *they* are making *today*.
And you want to fork the code and create your own version ? That's not
very nice. Maybe other project have a pool and they want to share. And
maybe turbine will see the benefits of sharing and decide to participate
in the library.
A lot of people claim the community is more important than the code - if
you can't get the community behind a FooPool, the code is not that
important.
> > What makes you think that whatever DBPool you choose will be better ? And
> > what makes you think that a project will be happy to replace some code
> > they developed and serve their purpose with something they have no control
> > over ?
>
> Why do you think that projects will be *required* to replace their code
> with the so-called 'library' code?
I was assuming the goal of the project is to have jakarta projects share
code - not to take common code without it's community and create another
project out of it.
Costin
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> I am interested in a component repository for the existing code in
> projects - where the projects can share the code if they choose to.
>
> It looks like in the current form, the library is duplicating Avalon -
> it's goal is to create productized server-side components, and I don't see
> any reason you'll need another project doing the same thing.
Well, if Avalon really is doing that, I am happy to shut up and go over
there...
But if not -
So far, the proposal was to start two subprojects, (1) DBCP and (2)
Testing, I think.
Why not add a third (3) Repository, lead by Costin, in the model of
all-inclusive, everyone gets a vote, add code and you're a committer,
aka 'JakartaForge'. That fits into the model, as a subproject, like a
regular Jakarta project, has reasonable control over it's destiny and
rules, so if anything goes, anything goes. It will certainly be a good
test to see how that community model works compared to the Jakarta
community model.
> All you have to do is contribute code to avalon, like any user, become a
> commiter - and then propose new components. I don't see any significant
> diference to require a new jakarta project. After all, the project goal
> is the same, and everything else is implementation detail ( i.e. how do
> you organize the code ) - and if you can propose it to avalon and be voted
> by existing avalon commiters.
Well, for a while there, Avalon was working under it's "cover charter",
claiming to be a 'framework' - when it's reborn here in Jakarta (isn't
that what is happening?), I guess we can see.
> > >From what I gathered our plan of attack was (1). ie Our first module would
> > be the DBPool. We would extract it from somewhere (say turbine) refactor
> > it. Then push it back into turbine with a wrapper that integrates it into
> > the turbine framework. We would then try to integrate it into struts and
> > anyone else that uses DB pools. Then we would pick another component and do
> > the same. Have I got this correct/wrong?
>
> And why not letting the original authors of a component decide for
> themself what to do with a component ? And why not let turbine decide if
> they want to share the component and how to do it ?
They do - they released the code under APL, sharing with everyone. But
they are currently choosing to keep it integrated in Turbine,
subordinate to the needs of turbine, and not documented as a separable
unit. That is the choice *they* are making *today*.
> What makes you think that whatever DBPool you choose will be better ? And
> what makes you think that a project will be happy to replace some code
> they developed and serve their purpose with something they have no control
> over ?
Why do you think that projects will be *required* to replace their code
with the so-called 'library' code?
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> I am interested in a component repository for the existing code in
> projects - where the projects can share the code if they choose to.
>
> It looks like in the current form, the library is duplicating Avalon -
> it's goal is to create productized server-side components, and I don't see
> any reason you'll need another project doing the same thing.
Well, if Avalon really is doing that, I am happy to shut up and go over
there...
But if not -
So far, the proposal was to start two subprojects, (1) DBCP and (2)
Testing, I think.
Why not add a third (3) Repository, lead by Costin, in the model of
all-inclusive, everyone gets a vote, add code and you're a committer,
aka 'JakartaForge'. That fits into the model, as a subproject, like a
regular Jakarta project, has reasonable control over it's destiny and
rules, so if anything goes, anything goes. It will certainly be a good
test to see how that community model works compared to the Jakarta
community model.
> All you have to do is contribute code to avalon, like any user, become a
> commiter - and then propose new components. I don't see any significant
> diference to require a new jakarta project. After all, the project goal
> is the same, and everything else is implementation detail ( i.e. how do
> you organize the code ) - and if you can propose it to avalon and be voted
> by existing avalon commiters.
Well, for a while there, Avalon was working under it's "cover charter",
claiming to be a 'framework' - when it's reborn here in Jakarta (isn't
that what is happening?), I guess we can see.
> > >From what I gathered our plan of attack was (1). ie Our first module would
> > be the DBPool. We would extract it from somewhere (say turbine) refactor
> > it. Then push it back into turbine with a wrapper that integrates it into
> > the turbine framework. We would then try to integrate it into struts and
> > anyone else that uses DB pools. Then we would pick another component and do
> > the same. Have I got this correct/wrong?
>
> And why not letting the original authors of a component decide for
> themself what to do with a component ? And why not let turbine decide if
> they want to share the component and how to do it ?
They do - they released the code under APL, sharing with everyone. But
they are currently choosing to keep it integrated in Turbine,
subordinate to the needs of turbine, and not documented as a separable
unit. That is the choice *they* are making *today*.
> What makes you think that whatever DBPool you choose will be better ? And
> what makes you think that a project will be happy to replace some code
> they developed and serve their purpose with something they have no control
> over ?
Why do you think that projects will be *required* to replace their code
with the so-called 'library' code?
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> >> In any case - I hope Ted will include the 2 proposals in the final vote,
> >> and I'll let the majority decide what will be the goal and rules for this
> >> project.
> >
> >As near as I can figure we have already covered that ground, and the
> >current proposal already reflects what the majority of people
> >contributing to this list have decided.
>
> I am kinda confused ;)
>
> A few days ago I indicated the 4 paths I saw were
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
> 4. gathering
>
> (3) is easily doable within current apache model. I believe Costin wants to
> work in (1) and Avalon covers enough of (2) that I don't see it worth
> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
> which I am -1 on at the moment.
I agree with this.
I am interested in a component repository for the existing code in
projects - where the projects can share the code if they choose to.
It looks like in the current form, the library is duplicating Avalon -
it's goal is to create productized server-side components, and I don't see
any reason you'll need another project doing the same thing.
All you have to do is contribute code to avalon, like any user, become a
commiter - and then propose new components. I don't see any significant
diference to require a new jakarta project. After all, the project goal
is the same, and everything else is implementation detail ( i.e. how do
you organize the code ) - and if you can propose it to avalon and be voted
by existing avalon commiters.
> >From what I gathered our plan of attack was (1). ie Our first module would
> be the DBPool. We would extract it from somewhere (say turbine) refactor
> it. Then push it back into turbine with a wrapper that integrates it into
> the turbine framework. We would then try to integrate it into struts and
> anyone else that uses DB pools. Then we would pick another component and do
> the same. Have I got this correct/wrong?
And why not letting the original authors of a component decide for
themself what to do with a component ? And why not let turbine decide if
they want to share the component and how to do it ?
What makes you think that whatever DBPool you choose will be better ? And
what makes you think that a project will be happy to replace some code
they developed and serve their purpose with something they have no control
over ?
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> >> In any case - I hope Ted will include the 2 proposals in the final vote,
> >> and I'll let the majority decide what will be the goal and rules for this
> >> project.
> >
> >As near as I can figure we have already covered that ground, and the
> >current proposal already reflects what the majority of people
> >contributing to this list have decided.
>
> I am kinda confused ;)
>
> A few days ago I indicated the 4 paths I saw were
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
> 4. gathering
>
> (3) is easily doable within current apache model. I believe Costin wants to
> work in (1) and Avalon covers enough of (2) that I don't see it worth
> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
> which I am -1 on at the moment.
I agree with this.
I am interested in a component repository for the existing code in
projects - where the projects can share the code if they choose to.
It looks like in the current form, the library is duplicating Avalon -
it's goal is to create productized server-side components, and I don't see
any reason you'll need another project doing the same thing.
All you have to do is contribute code to avalon, like any user, become a
commiter - and then propose new components. I don't see any significant
diference to require a new jakarta project. After all, the project goal
is the same, and everything else is implementation detail ( i.e. how do
you organize the code ) - and if you can propose it to avalon and be voted
by existing avalon commiters.
> >From what I gathered our plan of attack was (1). ie Our first module would
> be the DBPool. We would extract it from somewhere (say turbine) refactor
> it. Then push it back into turbine with a wrapper that integrates it into
> the turbine framework. We would then try to integrate it into struts and
> anyone else that uses DB pools. Then we would pick another component and do
> the same. Have I got this correct/wrong?
And why not letting the original authors of a component decide for
themself what to do with a component ? And why not let turbine decide if
they want to share the component and how to do it ?
What makes you think that whatever DBPool you choose will be better ? And
what makes you think that a project will be happy to replace some code
they developed and serve their purpose with something they have no control
over ?
Costin
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 08:40 22/2/01 -0500, Ted Husted wrote:
>cmanolache@yahoo.com wrote:
>> In any case - I hope Ted will include the 2 proposals in the final vote,
>> and I'll let the majority decide what will be the goal and rules for this
>> project.
>
>As near as I can figure we have already covered that ground, and the
>current proposal already reflects what the majority of people
>contributing to this list have decided.
I am kinda confused ;)
A few days ago I indicated the 4 paths I saw were
1. component repository (ie ToolForge+CJAN)
2. vetted/tested/approved components (ie Avalon+CJAN)
3. base util (Something similar to AUT - Apache Utility Toolkit).
4. gathering
(3) is easily doable within current apache model. I believe Costin wants to
work in (1) and Avalon covers enough of (2) that I don't see it worth
creating a new project for. So what am I saying? ;) I am +1 for all but (2)
which I am -1 on at the moment.
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> cmanolache@yahoo.com wrote:
> > In any case - I hope Ted will include the 2 proposals in the final vote,
> > and I'll let the majority decide what will be the goal and rules for this
> > project.
>
> As near as I can figure we have already covered that ground, and the
> current proposal already reflects what the majority of people
> contributing to this list have decided.
I haven't seen a final vote, only 2 rounds of polling, and on each round
there were proposals to refine the polling and reword some of the
questions.
> I am making my best effort, but if you feel differently, then you might
> like to submit a proposal of your own.
Sure, but why not reuse the existing one, and add one more choice to the
poll ? :-)
Costin
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 08:40 22/2/01 -0500, Ted Husted wrote:
>cmanolache@yahoo.com wrote:
>> In any case - I hope Ted will include the 2 proposals in the final vote,
>> and I'll let the majority decide what will be the goal and rules for this
>> project.
>
>As near as I can figure we have already covered that ground, and the
>current proposal already reflects what the majority of people
>contributing to this list have decided.
I am kinda confused ;)
A few days ago I indicated the 4 paths I saw were
1. component repository (ie ToolForge+CJAN)
2. vetted/tested/approved components (ie Avalon+CJAN)
3. base util (Something similar to AUT - Apache Utility Toolkit).
4. gathering
(3) is easily doable within current apache model. I believe Costin wants to
work in (1) and Avalon covers enough of (2) that I don't see it worth
creating a new project for. So what am I saying? ;) I am +1 for all but (2)
which I am -1 on at the moment.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> In any case - I hope Ted will include the 2 proposals in the final vote,
> and I'll let the majority decide what will be the goal and rules for this
> project.
As near as I can figure we have already covered that ground, and the
current proposal already reflects what the majority of people
contributing to this list have decided.
I am making my best effort, but if you feel differently, then you might
like to submit a proposal of your own.
We're all equal here; anyone with an email account can submit a proposal
to this list, the Jakarta PMC, or the ASF board, whenever they like.
-T.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> In any case - I hope Ted will include the 2 proposals in the final vote,
> and I'll let the majority decide what will be the goal and rules for this
> project.
As near as I can figure we have already covered that ground, and the
current proposal already reflects what the majority of people
contributing to this list have decided.
I am making my best effort, but if you feel differently, then you might
like to submit a proposal of your own.
We're all equal here; anyone with an email account can submit a proposal
to this list, the Jakarta PMC, or the ASF board, whenever they like.
-T.
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> > 1. A project should be able to share some code/components. I don't see
> > myself using or participating in a library that is not open to all
> > jakarta projects. And please don't call it library if the books are going
> > to be selected by "library commiters".
>
> 1) I never called it a *library*. That got stuck on by Ted et al. I
> wanted to call it 'Rupert', as there should be no preconcieved notions
> with that name. Apologies to anyone named 'Rupert' by the way. I would
> use 'Geir', but no one can pronounce it... :)
This list is named "library-dev", and the I was mislead into believing
the goal is to help projects to share code. That is something I am
interested in.
It seems you want to create (another) project that creates shared code (
avalon has exactly the same goal - if I read it corectly ).
> 2) Why wouldn't you use it? If the stuff is good, and the APIs stable,
> you would ignore it because, for example, Velocity (whose core has
There is a lot of good stuff around , and plenty of choices for any
component - I'll not "ignore", but I'll still look around for a
real library to contribute to.
> I guess, to follow the library analogy, a library still contains
> individual books, that have been edited, published, and then selected by
> the library. It's not like the general public stocks the shelves
> themselves....
I don't think so - the library collects books written, edited and
published by different people. I don't see how it can be called "open" if
a group of authors are voting to allow other authors to add books to the
library.
In any case - I hope Ted will include the 2 proposals in the final vote,
and I'll let the majority decide what will be the goal and rules for this
project.
I think it is very important to have a common place where projects can
share code - but it doesn't have to be this project. It's up to the
majority of each project to decide - and up to each individual to
contribute and use whatever project he feel is right. I'll keep looking
for a library :-)
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> > 1. A project should be able to share some code/components. I don't see
> > myself using or participating in a library that is not open to all
> > jakarta projects. And please don't call it library if the books are going
> > to be selected by "library commiters".
>
> 1) I never called it a *library*. That got stuck on by Ted et al. I
> wanted to call it 'Rupert', as there should be no preconcieved notions
> with that name. Apologies to anyone named 'Rupert' by the way. I would
> use 'Geir', but no one can pronounce it... :)
This list is named "library-dev", and the I was mislead into believing
the goal is to help projects to share code. That is something I am
interested in.
It seems you want to create (another) project that creates shared code (
avalon has exactly the same goal - if I read it corectly ).
> 2) Why wouldn't you use it? If the stuff is good, and the APIs stable,
> you would ignore it because, for example, Velocity (whose core has
There is a lot of good stuff around , and plenty of choices for any
component - I'll not "ignore", but I'll still look around for a
real library to contribute to.
> I guess, to follow the library analogy, a library still contains
> individual books, that have been edited, published, and then selected by
> the library. It's not like the general public stocks the shelves
> themselves....
I don't think so - the library collects books written, edited and
published by different people. I don't see how it can be called "open" if
a group of authors are voting to allow other authors to add books to the
library.
In any case - I hope Ted will include the 2 proposals in the final vote,
and I'll let the majority decide what will be the goal and rules for this
project.
I think it is very important to have a common place where projects can
share code - but it doesn't have to be this project. It's up to the
majority of each project to decide - and up to each individual to
contribute and use whatever project he feel is right. I'll keep looking
for a library :-)
Costin
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > > I would also like to ask for something like: if a project is using a
> > > component, and none of the project commiters are commiters for the
> > > component - the project as a whole should count as a commiter (
> > > i.e. should be able to request a temporary freeze, a tag, etc - so a
> > > "stable"/"predictible" version of the component can be included ).
> > > ( it that's not too much )
>
> There are 2 issues:
>
> 1. A project should be able to share some code/components. I don't see
> myself using or participating in a library that is not open to all
> jakarta projects. And please don't call it library if the books are going
> to be selected by "library commiters".
1) I never called it a *library*. That got stuck on by Ted et al. I
wanted to call it 'Rupert', as there should be no preconcieved notions
with that name. Apologies to anyone named 'Rupert' by the way. I would
use 'Geir', but no one can pronounce it... :)
2) Why wouldn't you use it? If the stuff is good, and the APIs stable,
you would ignore it because, for example, Velocity (whose core has
*nothing* to do with databases...) as a project doesn't have the right
to veto a move by the DB Connection Pool group to do <FOO> ?
> Yes, you may have duplication - but
> that's far better than having any group of people deciding what is the
> "right" way. I don't care how "expert" or good is the group that makes
> the selection - the library should be open to all jakarta projects
> that want to share something, and the users should decide for themself
> what to read.
Ok. This is true if it's a library in the classical sense. That's not
what I was looking for.
And why? Every other project with a scope and focus has a group
deciding the 'right way'. Tomcat has a group deciding the 'right way'.
I guess, to follow the library analogy, a library still contains
individual books, that have been edited, published, and then selected by
the library. It's not like the general public stocks the shelves
themselves....
>
> 2. If a component is going to be shared, and more than a jakarta project
> is going to use it - I would like all projects that are using the
> component to have at least the right to tag the workspace and veto/fork if
> a change is braking their code. Personally, I will not use a component in
> tomcat if that component is going to change without any control from
> tomcat - I would rather rewrite the component than risk the stability of
> the project and the release.
You can do that - if things really change, and you as a big user aren't
getting listened to, and your needs aren't being met - then take the
code and run. Why is this so different than the normal way of life?
> If a project is preparing for a release - it should be sure that it have
> stable components to use ( even if he's not involved in writing the
> components ).
Sure - just like I assume that tomcat is written to the released
(stable) servlet spec, the released (stable) JDK, etc.
- so if Tomcat uses the Jakarta Flargh component, specify the release
version. A project should make available release versions for users.
> Those are different items. I have no intention to participate in a
> "closed" library ( neither as writer nor reader ).
>
> I think (2) would do a lot in encouraging projects to use the library, but
> it's not that important for me ( well, as a tomcat commiter I would -1
> using a component that may change in the middle of a release without any
> way to control that from tomcat side - but other projects may want to take
> the risk ).
Again, why? Why not just specify the version of the released component
that you are using, and you are no longer at risk as long as that
version is still offered as a complete jar (or source jar, or
whatever...)
which could be required of the projects.
> > * This could result in a groady mess - if any 'regular Jakarta project'
> > can at any time for any reason start another 'library sub-project', then
> > there is *nothing* that compels people to work together.
>
> Any regular jakarta project can create code that is reusable - the library
> commiters don't have any monopoly on reusable code.
Right - true - but what I was looking for is a place for that resuable
code could be presented as such. I know that Turbine has a DBCP. But
it's not really clear. It's not clear how to use it. There are no
"Here's how you use the Turbine connection pool..." docs. There are no
usage examples of the Turbine connection pool, other than Turbine - and
if I am a casual user looking for a componet, why dig out of a framework
that offers no promises?
> And if a projects wants to share this code - I think the library is the
> right place, and the library commiters don't have a monopoly on "the right
> way to do a component" - only users can decide if they want to use a piece
> of code or not.
Of course only users decide. How could you even imagine forcing that?
And if a project wants to share, great. If there is something already
there that does the same thing that is documented and supported and ...
If another project had something to contribute to improve it, or make it
useful for someone else, that's another thing - it should be welcomed
and included. But ad-hoc creation of duplicate projects, or ad-hoc veto
power to arbitrary users should be contrained. I mean, Jakarta has only
one tomcat... I can't imagine Jakarta allowing another servlet container
project to start...
>
> > * This last suggestion promotes a project using a component from the
> > role of user to a 'default committer status' with veto power, without
> > any required investment in the project itself ?
>
> Yes - that's exactly what I'm sugesting. I don't think any project will (
> or should ) use a component if it doesn't have at least some control over
> the component.
Really? Will you drop whatever you are doing on Tomcat if *any* user
that uses it has some issue? Or do you carefully consider the issue,
and deal with it based on your charter and the community's interest as a
whole?
>
> > * This dilutes the potential for 'productizing' some of the things
> > present here in Jakarta into packaged, usable compoenents, since nothing
> > prevents 7 connection pools from being in existance.... I fear
> > duplication of effort again...
>
> Nothing should prevent 7 connection pools.
If they all do the same thing? What's the point? I don't get it. The
biggest CVS tree wins? We have 7 now, and no one knows where they are,
or how to use them, or where to find docs, or maybe there aren't docs,
etc, etc.
> If you want to prevent duplication you should make sure that every project
> feels it's better ( for the project goals ) to use the existing connection
> pool instead of writing another one.
YES. And I would hope that oversight by first the component
user/committer community, the 'Library-ubercommittee' or ultimately the
PMC, should help take care of that. Because if not, any project is free
to make as part of their project a connection pool, document it,
advertise it. Nothing will ever stop that.
Again : my hope was to bring together, for a given component, all the
projects that currently have implemented that component, and see if we
can find a common ground where a useful, sharable, and properly packaged
edition of that component can be offered for general use.
I have a feeling what we are each looking for doesn't share a large
enough basis set to make us both happy... alas...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> There are 2 issues:
> 1. A project should be able to share some code/components. I don't see
> myself using or participating in a library that is not open to all
> jakarta projects.
>> Committers join the library subproject in the same way they are entered to any Jakarta subproject.
This is what most people want, and so this is what will happen. Everyone
has heard the arguments, and made their decision. We voted, and it's
time to move on. If this is a showstopper for you, then so be it. No one
wants you to do anything you don't want to do.
> 2.
> If a project is preparing for a release - it should be sure that it have
> stable components to use ( even if he's not involved in writing the
> components ).
>> Each package has its own status file, release schedule, version number, QA tests, documentation, mailing list, and bug category.
Personally, I would build against the latest stable release of the
package, unless a feature I needed had been added to a nightly build. If
a later nightly build breaks my code, I can always roll back to the
latest one that didn't.
-T.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> There are 2 issues:
> 1. A project should be able to share some code/components. I don't see
> myself using or participating in a library that is not open to all
> jakarta projects.
>> Committers join the library subproject in the same way they are entered to any Jakarta subproject.
This is what most people want, and so this is what will happen. Everyone
has heard the arguments, and made their decision. We voted, and it's
time to move on. If this is a showstopper for you, then so be it. No one
wants you to do anything you don't want to do.
> 2.
> If a project is preparing for a release - it should be sure that it have
> stable components to use ( even if he's not involved in writing the
> components ).
>> Each package has its own status file, release schedule, version number, QA tests, documentation, mailing list, and bug category.
Personally, I would build against the latest stable release of the
package, unless a feature I needed had been added to a nightly build. If
a later nightly build breaks my code, I can always roll back to the
latest one that didn't.
-T.
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > > I would also like to ask for something like: if a project is using a
> > > component, and none of the project commiters are commiters for the
> > > component - the project as a whole should count as a commiter (
> > > i.e. should be able to request a temporary freeze, a tag, etc - so a
> > > "stable"/"predictible" version of the component can be included ).
> > > ( it that's not too much )
>
> There are 2 issues:
>
> 1. A project should be able to share some code/components. I don't see
> myself using or participating in a library that is not open to all
> jakarta projects. And please don't call it library if the books are going
> to be selected by "library commiters".
1) I never called it a *library*. That got stuck on by Ted et al. I
wanted to call it 'Rupert', as there should be no preconcieved notions
with that name. Apologies to anyone named 'Rupert' by the way. I would
use 'Geir', but no one can pronounce it... :)
2) Why wouldn't you use it? If the stuff is good, and the APIs stable,
you would ignore it because, for example, Velocity (whose core has
*nothing* to do with databases...) as a project doesn't have the right
to veto a move by the DB Connection Pool group to do <FOO> ?
> Yes, you may have duplication - but
> that's far better than having any group of people deciding what is the
> "right" way. I don't care how "expert" or good is the group that makes
> the selection - the library should be open to all jakarta projects
> that want to share something, and the users should decide for themself
> what to read.
Ok. This is true if it's a library in the classical sense. That's not
what I was looking for.
And why? Every other project with a scope and focus has a group
deciding the 'right way'. Tomcat has a group deciding the 'right way'.
I guess, to follow the library analogy, a library still contains
individual books, that have been edited, published, and then selected by
the library. It's not like the general public stocks the shelves
themselves....
>
> 2. If a component is going to be shared, and more than a jakarta project
> is going to use it - I would like all projects that are using the
> component to have at least the right to tag the workspace and veto/fork if
> a change is braking their code. Personally, I will not use a component in
> tomcat if that component is going to change without any control from
> tomcat - I would rather rewrite the component than risk the stability of
> the project and the release.
You can do that - if things really change, and you as a big user aren't
getting listened to, and your needs aren't being met - then take the
code and run. Why is this so different than the normal way of life?
> If a project is preparing for a release - it should be sure that it have
> stable components to use ( even if he's not involved in writing the
> components ).
Sure - just like I assume that tomcat is written to the released
(stable) servlet spec, the released (stable) JDK, etc.
- so if Tomcat uses the Jakarta Flargh component, specify the release
version. A project should make available release versions for users.
> Those are different items. I have no intention to participate in a
> "closed" library ( neither as writer nor reader ).
>
> I think (2) would do a lot in encouraging projects to use the library, but
> it's not that important for me ( well, as a tomcat commiter I would -1
> using a component that may change in the middle of a release without any
> way to control that from tomcat side - but other projects may want to take
> the risk ).
Again, why? Why not just specify the version of the released component
that you are using, and you are no longer at risk as long as that
version is still offered as a complete jar (or source jar, or
whatever...)
which could be required of the projects.
> > * This could result in a groady mess - if any 'regular Jakarta project'
> > can at any time for any reason start another 'library sub-project', then
> > there is *nothing* that compels people to work together.
>
> Any regular jakarta project can create code that is reusable - the library
> commiters don't have any monopoly on reusable code.
Right - true - but what I was looking for is a place for that resuable
code could be presented as such. I know that Turbine has a DBCP. But
it's not really clear. It's not clear how to use it. There are no
"Here's how you use the Turbine connection pool..." docs. There are no
usage examples of the Turbine connection pool, other than Turbine - and
if I am a casual user looking for a componet, why dig out of a framework
that offers no promises?
> And if a projects wants to share this code - I think the library is the
> right place, and the library commiters don't have a monopoly on "the right
> way to do a component" - only users can decide if they want to use a piece
> of code or not.
Of course only users decide. How could you even imagine forcing that?
And if a project wants to share, great. If there is something already
there that does the same thing that is documented and supported and ...
If another project had something to contribute to improve it, or make it
useful for someone else, that's another thing - it should be welcomed
and included. But ad-hoc creation of duplicate projects, or ad-hoc veto
power to arbitrary users should be contrained. I mean, Jakarta has only
one tomcat... I can't imagine Jakarta allowing another servlet container
project to start...
>
> > * This last suggestion promotes a project using a component from the
> > role of user to a 'default committer status' with veto power, without
> > any required investment in the project itself ?
>
> Yes - that's exactly what I'm sugesting. I don't think any project will (
> or should ) use a component if it doesn't have at least some control over
> the component.
Really? Will you drop whatever you are doing on Tomcat if *any* user
that uses it has some issue? Or do you carefully consider the issue,
and deal with it based on your charter and the community's interest as a
whole?
>
> > * This dilutes the potential for 'productizing' some of the things
> > present here in Jakarta into packaged, usable compoenents, since nothing
> > prevents 7 connection pools from being in existance.... I fear
> > duplication of effort again...
>
> Nothing should prevent 7 connection pools.
If they all do the same thing? What's the point? I don't get it. The
biggest CVS tree wins? We have 7 now, and no one knows where they are,
or how to use them, or where to find docs, or maybe there aren't docs,
etc, etc.
> If you want to prevent duplication you should make sure that every project
> feels it's better ( for the project goals ) to use the existing connection
> pool instead of writing another one.
YES. And I would hope that oversight by first the component
user/committer community, the 'Library-ubercommittee' or ultimately the
PMC, should help take care of that. Because if not, any project is free
to make as part of their project a connection pool, document it,
advertise it. Nothing will ever stop that.
Again : my hope was to bring together, for a given component, all the
projects that currently have implemented that component, and see if we
can find a common ground where a useful, sharable, and properly packaged
edition of that component can be offered for general use.
I have a feeling what we are each looking for doesn't share a large
enough basis set to make us both happy... alas...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> > I would also like to ask for something like: if a project is using a
> > component, and none of the project commiters are commiters for the
> > component - the project as a whole should count as a commiter (
> > i.e. should be able to request a temporary freeze, a tag, etc - so a
> > "stable"/"predictible" version of the component can be included ).
> > ( it that's not too much )
There are 2 issues:
1. A project should be able to share some code/components. I don't see
myself using or participating in a library that is not open to all
jakarta projects. And please don't call it library if the books are going
to be selected by "library commiters". Yes, you may have duplication - but
that's far better than having any group of people deciding what is the
"right" way. I don't care how "expert" or good is the group that makes
the selection - the library should be open to all jakarta projects
that want to share something, and the users should decide for themself
what to read.
2. If a component is going to be shared, and more than a jakarta project
is going to use it - I would like all projects that are using the
component to have at least the right to tag the workspace and veto/fork if
a change is braking their code. Personally, I will not use a component in
tomcat if that component is going to change without any control from
tomcat - I would rather rewrite the component than risk the stability of
the project and the release.
If a project is preparing for a release - it should be sure that it have
stable components to use ( even if he's not involved in writing the
components ).
Those are different items. I have no intention to participate in a
"closed" library ( neither as writer nor reader ).
I think (2) would do a lot in encouraging projects to use the library, but
it's not that important for me ( well, as a tomcat commiter I would -1
using a component that may change in the middle of a release without any
way to control that from tomcat side - but other projects may want to take
the risk ).
> * This could result in a groady mess - if any 'regular Jakarta project'
> can at any time for any reason start another 'library sub-project', then
> there is *nothing* that compels people to work together.
Any regular jakarta project can create code that is reusable - the library
commiters don't have any monopoly on reusable code.
And if a projects wants to share this code - I think the library is the
right place, and the library commiters don't have a monopoly on "the right
way to do a component" - only users can decide if they want to use a piece
of code or not.
> * This last suggestion promotes a project using a component from the
> role of user to a 'default committer status' with veto power, without
> any required investment in the project itself ?
Yes - that's exactly what I'm sugesting. I don't think any project will (
or should ) use a component if it doesn't have at least some control over
the component.
> * This dilutes the potential for 'productizing' some of the things
> present here in Jakarta into packaged, usable compoenents, since nothing
> prevents 7 connection pools from being in existance.... I fear
> duplication of effort again...
Nothing should prevent 7 connection pools.
If you want to prevent duplication you should make sure that every project
feels it's better ( for the project goals ) to use the existing connection
pool instead of writing another one.
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> > I would also like to ask for something like: if a project is using a
> > component, and none of the project commiters are commiters for the
> > component - the project as a whole should count as a commiter (
> > i.e. should be able to request a temporary freeze, a tag, etc - so a
> > "stable"/"predictible" version of the component can be included ).
> > ( it that's not too much )
There are 2 issues:
1. A project should be able to share some code/components. I don't see
myself using or participating in a library that is not open to all
jakarta projects. And please don't call it library if the books are going
to be selected by "library commiters". Yes, you may have duplication - but
that's far better than having any group of people deciding what is the
"right" way. I don't care how "expert" or good is the group that makes
the selection - the library should be open to all jakarta projects
that want to share something, and the users should decide for themself
what to read.
2. If a component is going to be shared, and more than a jakarta project
is going to use it - I would like all projects that are using the
component to have at least the right to tag the workspace and veto/fork if
a change is braking their code. Personally, I will not use a component in
tomcat if that component is going to change without any control from
tomcat - I would rather rewrite the component than risk the stability of
the project and the release.
If a project is preparing for a release - it should be sure that it have
stable components to use ( even if he's not involved in writing the
components ).
Those are different items. I have no intention to participate in a
"closed" library ( neither as writer nor reader ).
I think (2) would do a lot in encouraging projects to use the library, but
it's not that important for me ( well, as a tomcat commiter I would -1
using a component that may change in the middle of a release without any
way to control that from tomcat side - but other projects may want to take
the risk ).
> * This could result in a groady mess - if any 'regular Jakarta project'
> can at any time for any reason start another 'library sub-project', then
> there is *nothing* that compels people to work together.
Any regular jakarta project can create code that is reusable - the library
commiters don't have any monopoly on reusable code.
And if a projects wants to share this code - I think the library is the
right place, and the library commiters don't have a monopoly on "the right
way to do a component" - only users can decide if they want to use a piece
of code or not.
> * This last suggestion promotes a project using a component from the
> role of user to a 'default committer status' with veto power, without
> any required investment in the project itself ?
Yes - that's exactly what I'm sugesting. I don't think any project will (
or should ) use a component if it doesn't have at least some control over
the component.
> * This dilutes the potential for 'productizing' some of the things
> present here in Jakarta into packaged, usable compoenents, since nothing
> prevents 7 connection pools from being in existance.... I fear
> duplication of effort again...
Nothing should prevent 7 connection pools.
If you want to prevent duplication you should make sure that every project
feels it's better ( for the project goals ) to use the existing connection
pool instead of writing another one.
Costin
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > cmanolache@yahoo.com wrote:
> > > In other words: I'll vote +1 if the final proposal will explicitely allow
> > > projects to componentize and share their code, as Peter proposed (with
> > > the maintainers of the shared component becoming library commiters ).
> >
> > You mean something like:
> >
> > + Packages extracted from stable ASF products, and refactored by their
> > committers to current library standards, will also be accepted, along
> > with the original committers to the package.
>
> Yes.
>
> I would also like to ask for something like: if a project is using a
> component, and none of the project commiters are commiters for the
> component - the project as a whole should count as a commiter (
> i.e. should be able to request a temporary freeze, a tag, etc - so a
> "stable"/"predictible" version of the component can be included ).
> ( it that's not too much )
I'm sorry. I don't mean to be a stick in the mud, but I *just* don't
get it. I will try to be succinct.
* This breaks the conventional Jakarta model for no reason that has been
explicitly stated.
* This could result in a groady mess - if any 'regular Jakarta project'
can at any time for any reason start another 'library sub-project', then
there is *nothing* that compels people to work together.
* This last suggestion promotes a project using a component from the
role of user to a 'default committer status' with veto power, without
any required investment in the project itself ?
* This dilutes the potential for 'productizing' some of the things
present here in Jakarta into packaged, usable compoenents, since nothing
prevents 7 connection pools from being in existance.... I fear
duplication of effort again...
yadda, yadda, yadda...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > cmanolache@yahoo.com wrote:
> > > In other words: I'll vote +1 if the final proposal will explicitely allow
> > > projects to componentize and share their code, as Peter proposed (with
> > > the maintainers of the shared component becoming library commiters ).
> >
> > You mean something like:
> >
> > + Packages extracted from stable ASF products, and refactored by their
> > committers to current library standards, will also be accepted, along
> > with the original committers to the package.
>
> Yes.
>
> I would also like to ask for something like: if a project is using a
> component, and none of the project commiters are commiters for the
> component - the project as a whole should count as a commiter (
> i.e. should be able to request a temporary freeze, a tag, etc - so a
> "stable"/"predictible" version of the component can be included ).
> ( it that's not too much )
I'm sorry. I don't mean to be a stick in the mud, but I *just* don't
get it. I will try to be succinct.
* This breaks the conventional Jakarta model for no reason that has been
explicitly stated.
* This could result in a groady mess - if any 'regular Jakarta project'
can at any time for any reason start another 'library sub-project', then
there is *nothing* that compels people to work together.
* This last suggestion promotes a project using a component from the
role of user to a 'default committer status' with veto power, without
any required investment in the project itself ?
* This dilutes the potential for 'productizing' some of the things
present here in Jakarta into packaged, usable compoenents, since nothing
prevents 7 connection pools from being in existance.... I fear
duplication of effort again...
yadda, yadda, yadda...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
Posted by Morgan Delagrange <md...@yahoo.com>.
--- cmanolache@yahoo.com wrote:
> > cmanolache@yahoo.com wrote:
> > > In other words: I'll vote +1 if the final
> proposal will explicitely allow
> > > projects to componentize and share their code,
> as Peter proposed (with
> > > the maintainers of the shared component becoming
> library commiters ).
> >
> > You mean something like:
> >
> > + Packages extracted from stable ASF products, and
> refactored by their
> > committers to current library standards, will also
> be accepted, along
> > with the original committers to the package.
>
> Yes.
>
> I would also like to ask for something like: if a
> project is using a
> component, and none of the project commiters are
> commiters for the
> component - the project as a whole should count as a
> commiter (
> i.e. should be able to request a temporary freeze, a
> tag, etc - so a
> "stable"/"predictible" version of the component can
> be included ).
> ( it that's not too much )
>
> Costin
That sounds like a real maintenance nightmare to me.
It also breaks with the standard Jakarta paradigm for
subprojects. Subprojects can organize themselves
however they want, but they are not beholden to
non-committers. If every Jakarta subproject used one
or another component of the lib project (and that's
the idea), it would be anarchy.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [POLL] General Consensus, Round 2
Posted by Morgan Delagrange <md...@yahoo.com>.
--- cmanolache@yahoo.com wrote:
> > cmanolache@yahoo.com wrote:
> > > In other words: I'll vote +1 if the final
> proposal will explicitely allow
> > > projects to componentize and share their code,
> as Peter proposed (with
> > > the maintainers of the shared component becoming
> library commiters ).
> >
> > You mean something like:
> >
> > + Packages extracted from stable ASF products, and
> refactored by their
> > committers to current library standards, will also
> be accepted, along
> > with the original committers to the package.
>
> Yes.
>
> I would also like to ask for something like: if a
> project is using a
> component, and none of the project commiters are
> commiters for the
> component - the project as a whole should count as a
> commiter (
> i.e. should be able to request a temporary freeze, a
> tag, etc - so a
> "stable"/"predictible" version of the component can
> be included ).
> ( it that's not too much )
>
> Costin
That sounds like a real maintenance nightmare to me.
It also breaks with the standard Jakarta paradigm for
subprojects. Subprojects can organize themselves
however they want, but they are not beholden to
non-committers. If every Jakarta subproject used one
or another component of the lib project (and that's
the idea), it would be anarchy.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> cmanolache@yahoo.com wrote:
> > In other words: I'll vote +1 if the final proposal will explicitely allow
> > projects to componentize and share their code, as Peter proposed (with
> > the maintainers of the shared component becoming library commiters ).
>
> You mean something like:
>
> + Packages extracted from stable ASF products, and refactored by their
> committers to current library standards, will also be accepted, along
> with the original committers to the package.
Yes.
I would also like to ask for something like: if a project is using a
component, and none of the project commiters are commiters for the
component - the project as a whole should count as a commiter (
i.e. should be able to request a temporary freeze, a tag, etc - so a
"stable"/"predictible" version of the component can be included ).
( it that's not too much )
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
> cmanolache@yahoo.com wrote:
> > In other words: I'll vote +1 if the final proposal will explicitely allow
> > projects to componentize and share their code, as Peter proposed (with
> > the maintainers of the shared component becoming library commiters ).
>
> You mean something like:
>
> + Packages extracted from stable ASF products, and refactored by their
> committers to current library standards, will also be accepted, along
> with the original committers to the package.
Yes.
I would also like to ask for something like: if a project is using a
component, and none of the project commiters are commiters for the
component - the project as a whole should count as a commiter (
i.e. should be able to request a temporary freeze, a tag, etc - so a
"stable"/"predictible" version of the component can be included ).
( it that's not too much )
Costin
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> In other words: I'll vote +1 if the final proposal will explicitely allow
> projects to componentize and share their code, as Peter proposed (with
> the maintainers of the shared component becoming library commiters ).
You mean something like:
+ Packages extracted from stable ASF products, and refactored by their
committers to current library standards, will also be accepted, along
with the original committers to the package.
-T.
Re: [POLL] General Consensus, Round 2
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> In other words: I'll vote +1 if the final proposal will explicitely allow
> projects to componentize and share their code, as Peter proposed (with
> the maintainers of the shared component becoming library commiters ).
You mean something like:
+ Packages extracted from stable ASF products, and refactored by their
committers to current library standards, will also be accepted, along
with the original committers to the package.
-T.
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
On Fri, 23 Feb 2001, Peter Donald wrote:
> At 07:41 22/2/01 -0500, Ted Husted wrote:
>
> >+ Committers join the library subproject in the same way they are
> >entered to any Jakarta subproject. Being a committer in another Jakarta
> >subproject is not a prerequisite, nor does it provide free entry to the
> >library subproject.
>
> unless they are moving code from the other project and are willing to act
> as caregiver and guardian ;)
Peter, I think this would be a reasonable middle ground.
I'll change my vote to a +1 if we agree on this issue:
1. A new package can be added by a majority vote of the commiters OR by a
vote in a jakarta project that decides that a piece of the code is
general and there are people willing to move the code and maintain it.
2. The maintainers of the piece that is going to be shared will become
commiters on the library.
If this is going to be a library, any "author" should be allowed in, even
if it duplicates existing books or we don't agree with it's ideas - that
should be fundamental in a library.
Existing jakarta projects should be able to move existing code that is
going to be shared in the library - and the vote should be in the source
project ( since it'll be affected in quite a few ways - a piece that was
under their control will be shared with other projects and some people
will have to spend extra time making the code reusable and change the
project to use the reusable component ). I don't think the library should
be able to reject any particular project ( as long as the code follows the
library standards ).
Regarding commiters - you can have your way, I'm too tired and I have
other things to do then argue.
In other words: I'll vote +1 if the final proposal will explicitely allow
projects to componentize and share thier code, as Peter proposed (with
the maintainers of the shared component becoming library commiters ).
Costin
Re: [POLL] General Consensus, Round 2
Posted by cm...@yahoo.com.
On Fri, 23 Feb 2001, Peter Donald wrote:
> At 07:41 22/2/01 -0500, Ted Husted wrote:
>
> >+ Committers join the library subproject in the same way they are
> >entered to any Jakarta subproject. Being a committer in another Jakarta
> >subproject is not a prerequisite, nor does it provide free entry to the
> >library subproject.
>
> unless they are moving code from the other project and are willing to act
> as caregiver and guardian ;)
Peter, I think this would be a reasonable middle ground.
I'll change my vote to a +1 if we agree on this issue:
1. A new package can be added by a majority vote of the commiters OR by a
vote in a jakarta project that decides that a piece of the code is
general and there are people willing to move the code and maintain it.
2. The maintainers of the piece that is going to be shared will become
commiters on the library.
If this is going to be a library, any "author" should be allowed in, even
if it duplicates existing books or we don't agree with it's ideas - that
should be fundamental in a library.
Existing jakarta projects should be able to move existing code that is
going to be shared in the library - and the vote should be in the source
project ( since it'll be affected in quite a few ways - a piece that was
under their control will be shared with other projects and some people
will have to spend extra time making the code reusable and change the
project to use the reusable component ). I don't think the library should
be able to reject any particular project ( as long as the code follows the
library standards ).
Regarding commiters - you can have your way, I'm too tired and I have
other things to do then argue.
In other words: I'll vote +1 if the final proposal will explicitely allow
projects to componentize and share thier code, as Peter proposed (with
the maintainers of the shared component becoming library commiters ).
Costin
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 07:41 22/2/01 -0500, Ted Husted wrote:
>+ The primary unit of reuse and release is the package.
>
>+ The package library is not a framework but a repository of codebases
>designed to be shared.
>
>+ Each package must have a clearly defined purpose, scope, and API -- Do
>one thing well, and keep your contracts.
>
>+ Each library package is treated as a product in its own right.
>
>- - Each package has its own status file, release schedule, version
>number, QA tests, documentation, mailing list, and bug category.
egads ! ;) maybe not a separate mailing list ;) A general list may help
build a community. If it becomes crowded we can always split it up later.
Seeing discussion on components may prompt others to use that component.
>- - Each package must clearly specify any external dependencies,
>including any other library packages, and the earliest JDK version
>required.
>
>- - - External dependencies on optional and third-party codebases should
>be minimized.
>
>+ Each package maintains a list of its active committers in its status
>file.
>
>+ The packages should use a standard scheme for versioning, QA tests,
>and directory layouts, and a common format for documentation and Ant
>build files.
+10000000000000 ;)
>+ The packages should fit within a unified package hierarchy.
>
>+ In general, packages should define an abstract interface, and provide
>one or more implementations of that interface.
Not a requirement as such. A package should do one thing well. If there can
be multiple strategies for doing it then have interface-implementation
difference. However most components don't need to have multiple
implementations.
>+ The packages should have boring functional names. Implementations may
>choose more "exciting" designations.
>
>+ Packages are encouraged to either use JavaBeans as core objects, a
>JavaBean-style API, or to provide an optional JavaBean wrapper.
>
>+ External configuration files are discouraged, but if required, XML
>format files are preferred for configuration options.
and read in by one of the standard XML config systems (ie
digester/configuration or tomcat 3.xs one - whatever that is ;])
>+ The package library subproject shall be proposed as a Jakarta
>subproject.
>
>+ Each package will be hosted on its own page on the subproject Web
>site, and will also be indexed in a master catalog.
>
>+ The subproject catalog will also provide a distribution mechanism.
>
>+ The subproject will also host top-level "general" and "announcement"
>mailing lists.
>
>+ The subproject will also provide a single JAR of all stable package
>releases. It may also provide a second JAR with a subset of only JDK 1.1
>compatible releases. A gump of nightly builds will also be provided.
>
>+ Committers join the library subproject in the same way they are
>entered to any Jakarta subproject. Being a committer in another Jakarta
>subproject is not a prerequisite, nor does it provide free entry to the
>library subproject.
unless they are moving code from the other project and are willing to act
as caregiver and guardian ;)
>+ Each committer has karma for all the library packages, but is expected
>to add their name to a package's status file before their first commit
>to that package.
>
>+ The library committers shall elect a committee of three committers to
>provide general oversight, in the style of the Jakarta PMC.
If it's needed. Until we can an army of developers I would suggest that it
is just overhead. When we hit some critical mass (say 15-20 developers)
then this would be something to consider then.
>+ New packages may be proposed to the library general list, and voted on
>by all committers. To be accepted, a package proposal must receive a
>positive 3/4's vote of the library committers. Packages proposed are
>expected to be used by one or more ASF products.
>
Other than points above +1
>(2)
>
>NEW BUSINESS
>
>The first packages on the library agenda will be:
>
>JDBC connection pool
+0
Nice idea but I don't know enough to help ;) I could help with formalizing
the other boring process stuff and setting up build docs etc though...
>Testing Framework
>
>Work on these packages will coincide with work on the library subproject
>infrastructure.
>
>Additional codebases to consider for the Testing Framework include
>
>http://sourceforge.net/projects/j2eeunit - Vincent Massol
Theres also HttpUnit which would be very useful at Apache and it's "owner"
was amicable to donation last time I mentioned it ;) However we should make
sure it is adopted by projects inside Apache before we try to adopt such
projects.
>http://sourceforge.net/projects/arrowhead/ - Kevin Burton
It is dual licensed and GPLed so a no go unfortunately. It is however based
on testlet from avalon CVS under jakarta-avalon-testlet.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by Peter Donald <do...@apache.org>.
At 07:41 22/2/01 -0500, Ted Husted wrote:
>+ The primary unit of reuse and release is the package.
>
>+ The package library is not a framework but a repository of codebases
>designed to be shared.
>
>+ Each package must have a clearly defined purpose, scope, and API -- Do
>one thing well, and keep your contracts.
>
>+ Each library package is treated as a product in its own right.
>
>- - Each package has its own status file, release schedule, version
>number, QA tests, documentation, mailing list, and bug category.
egads ! ;) maybe not a separate mailing list ;) A general list may help
build a community. If it becomes crowded we can always split it up later.
Seeing discussion on components may prompt others to use that component.
>- - Each package must clearly specify any external dependencies,
>including any other library packages, and the earliest JDK version
>required.
>
>- - - External dependencies on optional and third-party codebases should
>be minimized.
>
>+ Each package maintains a list of its active committers in its status
>file.
>
>+ The packages should use a standard scheme for versioning, QA tests,
>and directory layouts, and a common format for documentation and Ant
>build files.
+10000000000000 ;)
>+ The packages should fit within a unified package hierarchy.
>
>+ In general, packages should define an abstract interface, and provide
>one or more implementations of that interface.
Not a requirement as such. A package should do one thing well. If there can
be multiple strategies for doing it then have interface-implementation
difference. However most components don't need to have multiple
implementations.
>+ The packages should have boring functional names. Implementations may
>choose more "exciting" designations.
>
>+ Packages are encouraged to either use JavaBeans as core objects, a
>JavaBean-style API, or to provide an optional JavaBean wrapper.
>
>+ External configuration files are discouraged, but if required, XML
>format files are preferred for configuration options.
and read in by one of the standard XML config systems (ie
digester/configuration or tomcat 3.xs one - whatever that is ;])
>+ The package library subproject shall be proposed as a Jakarta
>subproject.
>
>+ Each package will be hosted on its own page on the subproject Web
>site, and will also be indexed in a master catalog.
>
>+ The subproject catalog will also provide a distribution mechanism.
>
>+ The subproject will also host top-level "general" and "announcement"
>mailing lists.
>
>+ The subproject will also provide a single JAR of all stable package
>releases. It may also provide a second JAR with a subset of only JDK 1.1
>compatible releases. A gump of nightly builds will also be provided.
>
>+ Committers join the library subproject in the same way they are
>entered to any Jakarta subproject. Being a committer in another Jakarta
>subproject is not a prerequisite, nor does it provide free entry to the
>library subproject.
unless they are moving code from the other project and are willing to act
as caregiver and guardian ;)
>+ Each committer has karma for all the library packages, but is expected
>to add their name to a package's status file before their first commit
>to that package.
>
>+ The library committers shall elect a committee of three committers to
>provide general oversight, in the style of the Jakarta PMC.
If it's needed. Until we can an army of developers I would suggest that it
is just overhead. When we hit some critical mass (say 15-20 developers)
then this would be something to consider then.
>+ New packages may be proposed to the library general list, and voted on
>by all committers. To be accepted, a package proposal must receive a
>positive 3/4's vote of the library committers. Packages proposed are
>expected to be used by one or more ASF products.
>
Other than points above +1
>(2)
>
>NEW BUSINESS
>
>The first packages on the library agenda will be:
>
>JDBC connection pool
+0
Nice idea but I don't know enough to help ;) I could help with formalizing
the other boring process stuff and setting up build docs etc though...
>Testing Framework
>
>Work on these packages will coincide with work on the library subproject
>infrastructure.
>
>Additional codebases to consider for the Testing Framework include
>
>http://sourceforge.net/projects/j2eeunit - Vincent Massol
Theres also HttpUnit which would be very useful at Apache and it's "owner"
was amicable to donation last time I mentioned it ;) However we should make
sure it is adopted by projects inside Apache before we try to adopt such
projects.
>http://sourceforge.net/projects/arrowhead/ - Kevin Burton
It is dual licensed and GPLed so a no go unfortunately. It is however based
on testlet from avalon CVS under jakarta-avalon-testlet.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [POLL] General Consensus, Round 2
Posted by David Weinrich <dw...@home.com>.
On another almost related note, I sent off a reply to Round 1 and received
it locally, did it make it through to the list?
David
Re: [POLL] General Consensus, Round 2
Posted by Morgan Delagrange <md...@yahoo.com>.
+1. Why quibble? :)
--- Ted Husted <ne...@husted.com> wrote:
> (1)
>
> OLD BUSINESS
>
> To finalize the first round, I'd like to get a
> majority vote on these
> revised points of consensus. I believe these points
> represent the
> consensus opinion. In the interest of unity, if
> possible, please provide
> a single vote on the points as a block.
>
> This poll will expire in 5 days, or when the
> committers on the active
> roster (below) have responded.
>
> + The primary unit of reuse and release is the
> package.
>
> + The package library is not a framework but a
> repository of codebases
> designed to be shared.
>
> + Each package must have a clearly defined purpose,
> scope, and API -- Do
> one thing well, and keep your contracts.
>
> + Each library package is treated as a product in
> its own right.
>
> - - Each package has its own status file, release
> schedule, version
> number, QA tests, documentation, mailing list, and
> bug category.
>
> - - Each package must clearly specify any external
> dependencies,
> including any other library packages, and the
> earliest JDK version
> required.
>
> - - - External dependencies on optional and
> third-party codebases should
> be minimized.
>
> + Each package maintains a list of its active
> committers in its status
> file.
>
> + The packages should use a standard scheme for
> versioning, QA tests,
> and directory layouts, and a common format for
> documentation and Ant
> build files.
>
> + The packages should fit within a unified package
> hierarchy.
>
> + In general, packages should define an abstract
> interface, and provide
> one or more implementations of that interface.
>
> + The packages should have boring functional names.
> Implementations may
> choose more "exciting" designations.
>
> + Packages are encouraged to either use JavaBeans as
> core objects, a
> JavaBean-style API, or to provide an optional
> JavaBean wrapper.
>
> + External configuration files are discouraged, but
> if required, XML
> format files are preferred for configuration
> options.
>
> + The package library subproject shall be proposed
> as a Jakarta
> subproject.
>
> + Each package will be hosted on its own page on the
> subproject Web
> site, and will also be indexed in a master catalog.
>
> + The subproject catalog will also provide a
> distribution mechanism.
>
> + The subproject will also host top-level "general"
> and "announcement"
> mailing lists.
>
> + The subproject will also provide a single JAR of
> all stable package
> releases. It may also provide a second JAR with a
> subset of only JDK 1.1
> compatible releases. A gump of nightly builds will
> also be provided.
>
> + Committers join the library subproject in the same
> way they are
> entered to any Jakarta subproject. Being a committer
> in another Jakarta
> subproject is not a prerequisite, nor does it
> provide free entry to the
> library subproject.
>
> + Each committer has karma for all the library
> packages, but is expected
> to add their name to a package's status file before
> their first commit
> to that package.
>
> + The library committers shall elect a committee of
> three committers to
> provide general oversight, in the style of the
> Jakarta PMC.
>
> + New packages may be proposed to the library
> general list, and voted on
> by all committers. To be accepted, a package
> proposal must receive a
> positive 3/4's vote of the library committers.
> Packages proposed are
> expected to be used by one or more ASF products.
>
> (2)
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
>
> and
>
> Testing Framework
>
> Work on these packages will coincide with work on
> the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing
> Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent
> Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin
> Burton
>
> ---
>
> Roll of Active Committers (those responding to the
> last poll)
>
> Costin < cmanolache@yahoo.com >
> Rodney Waldhoff < rwald@hotmail.com >
> Ignacio J. Ortega < nacho@siapi.es >
> Bhamidi Krishna < bhamidik@hotmail.com >
> Geir Magnusson Jr. < geirm@optonline.net >
> Ted Husted < news.ted@husted.com >
> Federico Barbieri < scoobie@betaversion.org >
> Peter Donald < donaldp@apache.org >
> Ceki < cgu@qos.ch >
> Morgan Delagrange < mdelagra@yahoo.com >
>
> -Ted.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [POLL] General Consensus, Round 2
Posted by David Weinrich <dw...@home.com>.
+1 on these items as a whole. Sorry for the delay, just getting caught up
with the list now.
David Weinrich
On Thu, 22 Feb 2001, Ted Husted wrote:
> (1)
>
> OLD BUSINESS
>
> To finalize the first round, I'd like to get a majority vote on these
> revised points of consensus. I believe these points represent the
> consensus opinion. In the interest of unity, if possible, please provide
> a single vote on the points as a block.
>
> This poll will expire in 5 days, or when the committers on the active
> roster (below) have responded.
>
> + The primary unit of reuse and release is the package.
>
> + The package library is not a framework but a repository of codebases
> designed to be shared.
>
> + Each package must have a clearly defined purpose, scope, and API -- Do
> one thing well, and keep your contracts.
>
> + Each library package is treated as a product in its own right.
>
> - - Each package has its own status file, release schedule, version
> number, QA tests, documentation, mailing list, and bug category.
>
> - - Each package must clearly specify any external dependencies,
> including any other library packages, and the earliest JDK version
> required.
>
> - - - External dependencies on optional and third-party codebases should
> be minimized.
>
> + Each package maintains a list of its active committers in its status
> file.
>
> + The packages should use a standard scheme for versioning, QA tests,
> and directory layouts, and a common format for documentation and Ant
> build files.
>
> + The packages should fit within a unified package hierarchy.
>
> + In general, packages should define an abstract interface, and provide
> one or more implementations of that interface.
>
> + The packages should have boring functional names. Implementations may
> choose more "exciting" designations.
>
> + Packages are encouraged to either use JavaBeans as core objects, a
> JavaBean-style API, or to provide an optional JavaBean wrapper.
>
> + External configuration files are discouraged, but if required, XML
> format files are preferred for configuration options.
>
> + The package library subproject shall be proposed as a Jakarta
> subproject.
>
> + Each package will be hosted on its own page on the subproject Web
> site, and will also be indexed in a master catalog.
>
> + The subproject catalog will also provide a distribution mechanism.
>
> + The subproject will also host top-level "general" and "announcement"
> mailing lists.
>
> + The subproject will also provide a single JAR of all stable package
> releases. It may also provide a second JAR with a subset of only JDK 1.1
> compatible releases. A gump of nightly builds will also be provided.
>
> + Committers join the library subproject in the same way they are
> entered to any Jakarta subproject. Being a committer in another Jakarta
> subproject is not a prerequisite, nor does it provide free entry to the
> library subproject.
>
> + Each committer has karma for all the library packages, but is expected
> to add their name to a package's status file before their first commit
> to that package.
>
> + The library committers shall elect a committee of three committers to
> provide general oversight, in the style of the Jakarta PMC.
>
> + New packages may be proposed to the library general list, and voted on
> by all committers. To be accepted, a package proposal must receive a
> positive 3/4's vote of the library committers. Packages proposed are
> expected to be used by one or more ASF products.
>
> (2)
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
>
> and
>
> Testing Framework
>
> Work on these packages will coincide with work on the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin Burton
>
> ---
>
> Roll of Active Committers (those responding to the last poll)
>
> Costin < cmanolache@yahoo.com >
> Rodney Waldhoff < rwald@hotmail.com >
> Ignacio J. Ortega < nacho@siapi.es >
> Bhamidi Krishna < bhamidik@hotmail.com >
> Geir Magnusson Jr. < geirm@optonline.net >
> Ted Husted < news.ted@husted.com >
> Federico Barbieri < scoobie@betaversion.org >
> Peter Donald < donaldp@apache.org >
> Ceki < cgu@qos.ch >
> Morgan Delagrange < mdelagra@yahoo.com >
>
> -Ted.
>
Re: [POLL] General Consensus, Round 2
Posted by David Weinrich <dw...@home.com>.
+1 on these items as a whole. Sorry for the delay, just getting caught up
with the list now.
David Weinrich
On Thu, 22 Feb 2001, Ted Husted wrote:
> (1)
>
> OLD BUSINESS
>
> To finalize the first round, I'd like to get a majority vote on these
> revised points of consensus. I believe these points represent the
> consensus opinion. In the interest of unity, if possible, please provide
> a single vote on the points as a block.
>
> This poll will expire in 5 days, or when the committers on the active
> roster (below) have responded.
>
> + The primary unit of reuse and release is the package.
>
> + The package library is not a framework but a repository of codebases
> designed to be shared.
>
> + Each package must have a clearly defined purpose, scope, and API -- Do
> one thing well, and keep your contracts.
>
> + Each library package is treated as a product in its own right.
>
> - - Each package has its own status file, release schedule, version
> number, QA tests, documentation, mailing list, and bug category.
>
> - - Each package must clearly specify any external dependencies,
> including any other library packages, and the earliest JDK version
> required.
>
> - - - External dependencies on optional and third-party codebases should
> be minimized.
>
> + Each package maintains a list of its active committers in its status
> file.
>
> + The packages should use a standard scheme for versioning, QA tests,
> and directory layouts, and a common format for documentation and Ant
> build files.
>
> + The packages should fit within a unified package hierarchy.
>
> + In general, packages should define an abstract interface, and provide
> one or more implementations of that interface.
>
> + The packages should have boring functional names. Implementations may
> choose more "exciting" designations.
>
> + Packages are encouraged to either use JavaBeans as core objects, a
> JavaBean-style API, or to provide an optional JavaBean wrapper.
>
> + External configuration files are discouraged, but if required, XML
> format files are preferred for configuration options.
>
> + The package library subproject shall be proposed as a Jakarta
> subproject.
>
> + Each package will be hosted on its own page on the subproject Web
> site, and will also be indexed in a master catalog.
>
> + The subproject catalog will also provide a distribution mechanism.
>
> + The subproject will also host top-level "general" and "announcement"
> mailing lists.
>
> + The subproject will also provide a single JAR of all stable package
> releases. It may also provide a second JAR with a subset of only JDK 1.1
> compatible releases. A gump of nightly builds will also be provided.
>
> + Committers join the library subproject in the same way they are
> entered to any Jakarta subproject. Being a committer in another Jakarta
> subproject is not a prerequisite, nor does it provide free entry to the
> library subproject.
>
> + Each committer has karma for all the library packages, but is expected
> to add their name to a package's status file before their first commit
> to that package.
>
> + The library committers shall elect a committee of three committers to
> provide general oversight, in the style of the Jakarta PMC.
>
> + New packages may be proposed to the library general list, and voted on
> by all committers. To be accepted, a package proposal must receive a
> positive 3/4's vote of the library committers. Packages proposed are
> expected to be used by one or more ASF products.
>
> (2)
>
> NEW BUSINESS
>
> The first packages on the library agenda will be:
>
> JDBC connection pool
>
> and
>
> Testing Framework
>
> Work on these packages will coincide with work on the library subproject
> infrastructure.
>
> Additional codebases to consider for the Testing Framework include
>
> http://sourceforge.net/projects/j2eeunit - Vincent Massol
> http://sourceforge.net/projects/arrowhead/ - Kevin Burton
>
> ---
>
> Roll of Active Committers (those responding to the last poll)
>
> Costin < cmanolache@yahoo.com >
> Rodney Waldhoff < rwald@hotmail.com >
> Ignacio J. Ortega < nacho@siapi.es >
> Bhamidi Krishna < bhamidik@hotmail.com >
> Geir Magnusson Jr. < geirm@optonline.net >
> Ted Husted < news.ted@husted.com >
> Federico Barbieri < scoobie@betaversion.org >
> Peter Donald < donaldp@apache.org >
> Ceki < cgu@qos.ch >
> Morgan Delagrange < mdelagra@yahoo.com >
>
> -Ted.
>
Re: [POLL] General Consensus, Round 2
Posted by David Weinrich <dw...@home.com>.
On another almost related note, I sent off a reply to Round 1 and received
it locally, did it make it through to the list?
David