You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Ted Husted <ne...@husted.com> on 2001/02/28 17:24:13 UTC
[VOTE] Initial Proposal - Re: Consensus ?
I suggest that after the PMC new-member vote shakes out, we should
submit a proposal in the form of
< http://husted.com/about/jakarta/lib005.htm >
Since the vote on this sort-of evolved, I'm grandfathering these four
+1's
+1 Morgan Delagrange
+1 Costin
+1 Ignacio J. Ortega
+1 David Weinrich
Also feel free to suggest a name for the subproject, if you think
Library is too bland. Suggestions have been Agora, Rupert, and Zarf.
Clarification:
The catalog can be a feature of the Library's Web site infrastructure.
Also:
Peter made a nice offer about merging this into Avalon, and maybe
breaking it out later. It's a sound idea, but personally, I would lean
toward starting this as a standalone subproject, so it would be easier
to find (which is pretty much the point).
-Ted.
Re: [VOTE] Initial Proposal - Re: Consensus ?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
My vote appears moot : there is serious consensus. Just to make it
clear where I stand :
> (0) rationale
+1
> (1) scope of the subproject
+1
> (1.5) interaction with other subprojects
> (1.5.1) the sandbox
> The subproject will host a CVS will be available to all
> Jakarta committers as a workplace for new packages.
> Before release to the public, a sandbox package
> must be accepted to the library, or sponsored by another Jakarta subproject.
+1 : there is a typo in the first line. Can the second sentence can be
summed up as - "The sandbox is not for released projects." And leave
the release possiblities out of it as they will change over time?
Finally, will the sandbox CVS be separate? I think it should be. Just
like I think each subproject should have a separate CVS.
> (1.5.2) the directory
> The subproject will also catalog packages available to the
> public through other Jakarta subprojects and ASF projects,
> similar in functionality to <download.com> , < cpan.org >,
> or < SourceForge.net > (user portion). This will be a dynamic
> catalog, and new entries may be added by Jakarta committers,
> developers, and users. Entries by developers and users will be
> approved before being made public.
+1 I think the phrasing "similar to..." doesn't add anything, and
could be replaced with a clear statement of purpose : "...and ASF
projects, providing a central directory of resources that are found in
the Jakarta project codebases, including but not limited to sourcecode,
FAQ's, How-To, etc." Or something to that effect.
> (2) identify the initial source from which the subproject is to be populated
> The initial packages would be based on existing ASF codebases,
> including those that provide services for DataSource/Database Pools,
> XML Configuration, Message Resources and i18n, JNDI and Naming,
> and Testing Suites. The initial committers have agreed to first create
> and maintain a Database Connection Pool package, along with related
> testing suites and subproject infrastructure.
+1
> (3) identify the mailing list(s) if any which are to be created
> jakarta-commons-general
> jakarta-commons-DBCP (database connection pool)
+1 : and maybe note that any subproject living here will have a list?
Otherwise it will get too noisy if sandbox and directory has to use
general
jakarta-${NAME}-sandbox
jakarta-${NAME}-directory
jakarta-${NAME}-foo
> (4) identify the initial set of committers
+1 : can we just put Craig down to? :)
> Subproject Guidelines
Assume +1 except for
> 7.In general, packages should define an abstract interface, and
provide one or more implementations of that interface.
Note not required : a package can support an existing standard abstract
interface as well (a la JDBC).
> 13.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.
Do we address anywhere that each package should have it's own build
target producing a jar containing only that package? Decouples version
dependencies as a set.
> 15.Each committer has karma to all the library packages, but is expected to add their name to a package's status file before their first commit to that package.
-1. I still don't like this.
> 20.The subproject CVS will be available to all Jakarta committers as a sandbox for new packages. Before release
to the public, a sandbox package must be accepted to the library,
or sponsored by another Jakarta subproject.
Does this need to be amended to recognize jakarta-${NAME}-sandbox as a
separate entity that has the open CVS?
> Subproject name
> Agora
-1 : although I think this is a great name for 'sandbox'.
> Commons (with Library, Sandbox, and Directory services)
-1 on the 'with' part.
+1 for the name 'Commons'
> Rupert
-1 : I wasn't being serious when I proposed this :) It was just to be a
meta-name
> Share
+1
<whew>
Great job, all. Thanks for organizing, Ted.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] Initial Proposal - Re: Consensus ?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
My vote appears moot : there is serious consensus. Just to make it
clear where I stand :
> (0) rationale
+1
> (1) scope of the subproject
+1
> (1.5) interaction with other subprojects
> (1.5.1) the sandbox
> The subproject will host a CVS will be available to all
> Jakarta committers as a workplace for new packages.
> Before release to the public, a sandbox package
> must be accepted to the library, or sponsored by another Jakarta subproject.
+1 : there is a typo in the first line. Can the second sentence can be
summed up as - "The sandbox is not for released projects." And leave
the release possiblities out of it as they will change over time?
Finally, will the sandbox CVS be separate? I think it should be. Just
like I think each subproject should have a separate CVS.
> (1.5.2) the directory
> The subproject will also catalog packages available to the
> public through other Jakarta subprojects and ASF projects,
> similar in functionality to <download.com> , < cpan.org >,
> or < SourceForge.net > (user portion). This will be a dynamic
> catalog, and new entries may be added by Jakarta committers,
> developers, and users. Entries by developers and users will be
> approved before being made public.
+1 I think the phrasing "similar to..." doesn't add anything, and
could be replaced with a clear statement of purpose : "...and ASF
projects, providing a central directory of resources that are found in
the Jakarta project codebases, including but not limited to sourcecode,
FAQ's, How-To, etc." Or something to that effect.
> (2) identify the initial source from which the subproject is to be populated
> The initial packages would be based on existing ASF codebases,
> including those that provide services for DataSource/Database Pools,
> XML Configuration, Message Resources and i18n, JNDI and Naming,
> and Testing Suites. The initial committers have agreed to first create
> and maintain a Database Connection Pool package, along with related
> testing suites and subproject infrastructure.
+1
> (3) identify the mailing list(s) if any which are to be created
> jakarta-commons-general
> jakarta-commons-DBCP (database connection pool)
+1 : and maybe note that any subproject living here will have a list?
Otherwise it will get too noisy if sandbox and directory has to use
general
jakarta-${NAME}-sandbox
jakarta-${NAME}-directory
jakarta-${NAME}-foo
> (4) identify the initial set of committers
+1 : can we just put Craig down to? :)
> Subproject Guidelines
Assume +1 except for
> 7.In general, packages should define an abstract interface, and
provide one or more implementations of that interface.
Note not required : a package can support an existing standard abstract
interface as well (a la JDBC).
> 13.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.
Do we address anywhere that each package should have it's own build
target producing a jar containing only that package? Decouples version
dependencies as a set.
> 15.Each committer has karma to all the library packages, but is expected to add their name to a package's status file before their first commit to that package.
-1. I still don't like this.
> 20.The subproject CVS will be available to all Jakarta committers as a sandbox for new packages. Before release
to the public, a sandbox package must be accepted to the library,
or sponsored by another Jakarta subproject.
Does this need to be amended to recognize jakarta-${NAME}-sandbox as a
separate entity that has the open CVS?
> Subproject name
> Agora
-1 : although I think this is a great name for 'sandbox'.
> Commons (with Library, Sandbox, and Directory services)
-1 on the 'with' part.
+1 for the name 'Commons'
> Rupert
-1 : I wasn't being serious when I proposed this :) It was just to be a
meta-name
> Share
+1
<whew>
Great job, all. Thanks for organizing, Ted.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] Initial Proposal - Re: Consensus ?
Posted by Peter Donald <do...@apache.org>.
At 07:08 28/2/01 -0800, David Weinrich wrote:
>> So we have the Scaffold, the ScratchPad and the Commons. All of these are
>> infrastructure points rather than content.
>
>I absolutely agree if you switch /content/products/ and swap some names
>around ;). Essentially the Commons Project is an infrastructure of support
>services for jakarta ( my vision at least... YVMV ). Having it as a
>seperate project helps us develop the methods and processes to do this in
>a way that doesn't intrude upon the internal development of the jakarta
>projects. As the project develops and services mature, projects can start
>using them for what they are without disturbing what exists within that
>project.
+10000 ;)
>> Leaving aside Commons for the
>> moment, the other two should be integrated into all projects IMHO. Some
>> projects allow ScratchPad work to occur in main CVS tree, others use
>> branches, whiteboard directories, proposal directories and contrib
>> directories. The Scaffold would benefit all jakarta projects.
>>
>
>I agree and disagree at the same time. If by integrate you mean 'can be
>used by all projects as they see fit' I agree. If you mean 'will each
>implement in their own way' I disagree. Part of what I think this project
>provides is some of the support services/infrastructure to do these things
>without forcing each project to do them on their own ( reuse on a human
>resources scale if you want to look at it that way). In a way it is a
>place for myself and people who want to contribute *something* but lack
>the expertise to build a framework product to contribute to the jakarta
>project in a way that benefits all of the project. To push the library
>image a bit too far... I don't mind being the person that fills the card
>catalog and puts the books back on the shelves if the project on the
>whole needs that work done and it will free up the people who *don't*
>want to have to do that on but end up doing them anyways out of necessity.
A little bit of push and a little bit of pull would be what I advocate.
Take gump - it is mainly Sams iniative but by sending out mails saying
(your code is broken!!!) it motivates the committers to make changes and
integrate gumps ways into their own ;) Hopefully when Gump includes unit
testing it may be possible to give even more exhaustive feedback to
different groups. In time gump could also notify upstream providers when a
change they make breaks downstream users. it could also integrate things
like statistics and metrics. All of these features are mostly implemented
by Sam but it also should form a feedback loop so that the committers of
each project collaborate more.
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: [VOTE] Initial Proposal - Re: Consensus ?
Posted by Peter Donald <do...@apache.org>.
At 07:08 28/2/01 -0800, David Weinrich wrote:
>> So we have the Scaffold, the ScratchPad and the Commons. All of these are
>> infrastructure points rather than content.
>
>I absolutely agree if you switch /content/products/ and swap some names
>around ;). Essentially the Commons Project is an infrastructure of support
>services for jakarta ( my vision at least... YVMV ). Having it as a
>seperate project helps us develop the methods and processes to do this in
>a way that doesn't intrude upon the internal development of the jakarta
>projects. As the project develops and services mature, projects can start
>using them for what they are without disturbing what exists within that
>project.
+10000 ;)
>> Leaving aside Commons for the
>> moment, the other two should be integrated into all projects IMHO. Some
>> projects allow ScratchPad work to occur in main CVS tree, others use
>> branches, whiteboard directories, proposal directories and contrib
>> directories. The Scaffold would benefit all jakarta projects.
>>
>
>I agree and disagree at the same time. If by integrate you mean 'can be
>used by all projects as they see fit' I agree. If you mean 'will each
>implement in their own way' I disagree. Part of what I think this project
>provides is some of the support services/infrastructure to do these things
>without forcing each project to do them on their own ( reuse on a human
>resources scale if you want to look at it that way). In a way it is a
>place for myself and people who want to contribute *something* but lack
>the expertise to build a framework product to contribute to the jakarta
>project in a way that benefits all of the project. To push the library
>image a bit too far... I don't mind being the person that fills the card
>catalog and puts the books back on the shelves if the project on the
>whole needs that work done and it will free up the people who *don't*
>want to have to do that on but end up doing them anyways out of necessity.
A little bit of push and a little bit of pull would be what I advocate.
Take gump - it is mainly Sams iniative but by sending out mails saying
(your code is broken!!!) it motivates the committers to make changes and
integrate gumps ways into their own ;) Hopefully when Gump includes unit
testing it may be possible to give even more exhaustive feedback to
different groups. In time gump could also notify upstream providers when a
change they make breaks downstream users. it could also integrate things
like statistics and metrics. All of these features are mostly implemented
by Sam but it also should form a feedback loop so that the committers of
each project collaborate more.
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: [VOTE] Initial Proposal - Re: Consensus ?
Posted by David Weinrich <dw...@home.com>.
On Thu, 1 Mar 2001, Peter Donald wrote:
> Hi,
>
> Not to be a stick in the mud but ...
S'Ok, I'll be a stick in the mud too... :)
> what this sounds like is Avalon ;) It
> is true that most discussion on Avalon is concerned about the
> pattern/framework (or more specifically the kernel aspect of the previous).
> However what is proposed is still overlapping with Avalon stated purpose
> (ie place where server components for Apache are located). Damn I feel like
> a broken record here.
>
> Perhaps it is better to analyze the infrastructure rather than the content.
> Many seem to want a CJAN distribution system for use both internally and
> externally to apache. CJAN would serve as a distribution point for
> products. Add a directory on top of CJAN and you have a catalog.
> Standardize the layout/structure/testing/gumpiness/whatever of each product
> and your a few more steps in the right direction. So I see
> Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
> discussion.
This is what I identified as the Catalog Service/Dewey in a recent email (
just so I can match up the ideas with each of the names we are using )
>
> Another point identified is the need for a scratch pad CVS for giving birth
> to new components.
>
> Another point is shared CVS access - lets call this the Commons.
>
These two are what we have discussed as the Agora Service ( aka sandbox
and whatnot ) and they are pretty much rolled in together. The scratch pad
is facilitated by shared CVS access, and the development of tools is
facilitated by both so...
The 'Commons' is the word I proposed to denote the project as a whole, a
collection of services that facilitate re-use and shared components/code
between projects.
> So we have the Scaffold, the ScratchPad and the Commons. All of these are
> infrastructure points rather than content.
I absolutely agree if you switch /content/products/ and swap some names
around ;). Essentially the Commons Project is an infrastructure of support
services for jakarta ( my vision at least... YVMV ). Having it as a
seperate project helps us develop the methods and processes to do this in
a way that doesn't intrude upon the internal development of the jakarta
projects. As the project develops and services mature, projects can start
using them for what they are without disturbing what exists within that
project.
> Leaving aside Commons for the
> moment, the other two should be integrated into all projects IMHO. Some
> projects allow ScratchPad work to occur in main CVS tree, others use
> branches, whiteboard directories, proposal directories and contrib
> directories. The Scaffold would benefit all jakarta projects.
>
I agree and disagree at the same time. If by integrate you mean 'can be
used by all projects as they see fit' I agree. If you mean 'will each
implement in their own way' I disagree. Part of what I think this project
provides is some of the support services/infrastructure to do these things
without forcing each project to do them on their own ( reuse on a human
resources scale if you want to look at it that way). In a way it is a
place for myself and people who want to contribute *something* but lack
the expertise to build a framework product to contribute to the jakarta
project in a way that benefits all of the project. To push the library
image a bit too far... I don't mind being the person that fills the card
catalog and puts the books back on the shelves if the project on the
whole needs that work done and it will free up the people who *don't*
want to have to do that on but end up doing them anyways out of necessity.
> The Commons is something I would like to see aswell but there does not seem
> to be a lot of support for it aside from Sam at the momment ;)
>
> So now onto content.
>
> Does this project overlap with Avalons stated purpose? Largely it is
> identical. Provide a place to share server-side components between Apache
> projects. You could complain that Avalon is too integrated or too
> frameworky then there is a perfect place to start fixing it ;) My concern
> is that with two projects with identical purposes is going to cause a
> little confusion. Worse yet I have a feeling that it may be possible that
> the same issues/mistakes/problems that occur within Avalon will occur
> within this project. I think Sam referred to Avalon as the eternal alpha
> project (IIRC it has been around for about 3 years and is only starting to
> stabilize recently).
Here is my take on this: Avalon is a pre-existing project that has
something of a mixed/varying purpose. From the outside the project appears
to be a framework/kernel/system of developing server software in java.
Re: [VOTE] Initial Proposal - Re: Consensus ?
Posted by David Weinrich <dw...@home.com>.
On Thu, 1 Mar 2001, Peter Donald wrote:
> Hi,
>
> Not to be a stick in the mud but ...
S'Ok, I'll be a stick in the mud too... :)
> what this sounds like is Avalon ;) It
> is true that most discussion on Avalon is concerned about the
> pattern/framework (or more specifically the kernel aspect of the previous).
> However what is proposed is still overlapping with Avalon stated purpose
> (ie place where server components for Apache are located). Damn I feel like
> a broken record here.
>
> Perhaps it is better to analyze the infrastructure rather than the content.
> Many seem to want a CJAN distribution system for use both internally and
> externally to apache. CJAN would serve as a distribution point for
> products. Add a directory on top of CJAN and you have a catalog.
> Standardize the layout/structure/testing/gumpiness/whatever of each product
> and your a few more steps in the right direction. So I see
> Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
> discussion.
This is what I identified as the Catalog Service/Dewey in a recent email (
just so I can match up the ideas with each of the names we are using )
>
> Another point identified is the need for a scratch pad CVS for giving birth
> to new components.
>
> Another point is shared CVS access - lets call this the Commons.
>
These two are what we have discussed as the Agora Service ( aka sandbox
and whatnot ) and they are pretty much rolled in together. The scratch pad
is facilitated by shared CVS access, and the development of tools is
facilitated by both so...
The 'Commons' is the word I proposed to denote the project as a whole, a
collection of services that facilitate re-use and shared components/code
between projects.
> So we have the Scaffold, the ScratchPad and the Commons. All of these are
> infrastructure points rather than content.
I absolutely agree if you switch /content/products/ and swap some names
around ;). Essentially the Commons Project is an infrastructure of support
services for jakarta ( my vision at least... YVMV ). Having it as a
seperate project helps us develop the methods and processes to do this in
a way that doesn't intrude upon the internal development of the jakarta
projects. As the project develops and services mature, projects can start
using them for what they are without disturbing what exists within that
project.
> Leaving aside Commons for the
> moment, the other two should be integrated into all projects IMHO. Some
> projects allow ScratchPad work to occur in main CVS tree, others use
> branches, whiteboard directories, proposal directories and contrib
> directories. The Scaffold would benefit all jakarta projects.
>
I agree and disagree at the same time. If by integrate you mean 'can be
used by all projects as they see fit' I agree. If you mean 'will each
implement in their own way' I disagree. Part of what I think this project
provides is some of the support services/infrastructure to do these things
without forcing each project to do them on their own ( reuse on a human
resources scale if you want to look at it that way). In a way it is a
place for myself and people who want to contribute *something* but lack
the expertise to build a framework product to contribute to the jakarta
project in a way that benefits all of the project. To push the library
image a bit too far... I don't mind being the person that fills the card
catalog and puts the books back on the shelves if the project on the
whole needs that work done and it will free up the people who *don't*
want to have to do that on but end up doing them anyways out of necessity.
> The Commons is something I would like to see aswell but there does not seem
> to be a lot of support for it aside from Sam at the momment ;)
>
> So now onto content.
>
> Does this project overlap with Avalons stated purpose? Largely it is
> identical. Provide a place to share server-side components between Apache
> projects. You could complain that Avalon is too integrated or too
> frameworky then there is a perfect place to start fixing it ;) My concern
> is that with two projects with identical purposes is going to cause a
> little confusion. Worse yet I have a feeling that it may be possible that
> the same issues/mistakes/problems that occur within Avalon will occur
> within this project. I think Sam referred to Avalon as the eternal alpha
> project (IIRC it has been around for about 3 years and is only starting to
> stabilize recently).
Here is my take on this: Avalon is a pre-existing project that has
something of a mixed/varying purpose. From the outside the project appears
to be a framework/kernel/system of developing server software in java.
Re: [VOTE] Initial Proposal - Re: Consensus ?
Posted by Peter Donald <do...@apache.org>.
Hi,
Not to be a stick in the mud but ... what this sounds like is Avalon ;) It
is true that most discussion on Avalon is concerned about the
pattern/framework (or more specifically the kernel aspect of the previous).
However what is proposed is still overlapping with Avalon stated purpose
(ie place where server components for Apache are located). Damn I feel like
a broken record here.
Perhaps it is better to analyze the infrastructure rather than the content.
Many seem to want a CJAN distribution system for use both internally and
externally to apache. CJAN would serve as a distribution point for
products. Add a directory on top of CJAN and you have a catalog.
Standardize the layout/structure/testing/gumpiness/whatever of each product
and your a few more steps in the right direction. So I see
Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
discussion.
Another point identified is the need for a scratch pad CVS for giving birth
to new components.
Another point is shared CVS access - lets call this the Commons.
So we have the Scaffold, the ScratchPad and the Commons. All of these are
infrastructure points rather than content. Leaving aside Commons for the
moment, the other two should be integrated into all projects IMHO. Some
projects allow ScratchPad work to occur in main CVS tree, others use
branches, whiteboard directories, proposal directories and contrib
directories. The Scaffold would benefit all jakarta projects.
The Commons is something I would like to see aswell but there does not seem
to be a lot of support for it aside from Sam at the momment ;)
So now onto content.
Does this project overlap with Avalons stated purpose? Largely it is
identical. Provide a place to share server-side components between Apache
projects. You could complain that Avalon is too integrated or too
frameworky then there is a perfect place to start fixing it ;) My concern
is that with two projects with identical purposes is going to cause a
little confusion. Worse yet I have a feeling that it may be possible that
the same issues/mistakes/problems that occur within Avalon will occur
within this project. I think Sam referred to Avalon as the eternal alpha
project (IIRC it has been around for about 3 years and is only starting to
stabilize recently).
Speaking for myself (and not for Avalon group) I would love to see a
flattening of CVS access and allow an area to develope and maintain these
different components within Avalon. I don't care about the politics of each
component - as long as they are labeled as STABLE/ALPHA/BETA/whatever and
stick to it.
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: [VOTE] Initial Proposal - Re: Consensus ?
Posted by Peter Donald <do...@apache.org>.
Hi,
Not to be a stick in the mud but ... what this sounds like is Avalon ;) It
is true that most discussion on Avalon is concerned about the
pattern/framework (or more specifically the kernel aspect of the previous).
However what is proposed is still overlapping with Avalon stated purpose
(ie place where server components for Apache are located). Damn I feel like
a broken record here.
Perhaps it is better to analyze the infrastructure rather than the content.
Many seem to want a CJAN distribution system for use both internally and
externally to apache. CJAN would serve as a distribution point for
products. Add a directory on top of CJAN and you have a catalog.
Standardize the layout/structure/testing/gumpiness/whatever of each product
and your a few more steps in the right direction. So I see
Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
discussion.
Another point identified is the need for a scratch pad CVS for giving birth
to new components.
Another point is shared CVS access - lets call this the Commons.
So we have the Scaffold, the ScratchPad and the Commons. All of these are
infrastructure points rather than content. Leaving aside Commons for the
moment, the other two should be integrated into all projects IMHO. Some
projects allow ScratchPad work to occur in main CVS tree, others use
branches, whiteboard directories, proposal directories and contrib
directories. The Scaffold would benefit all jakarta projects.
The Commons is something I would like to see aswell but there does not seem
to be a lot of support for it aside from Sam at the momment ;)
So now onto content.
Does this project overlap with Avalons stated purpose? Largely it is
identical. Provide a place to share server-side components between Apache
projects. You could complain that Avalon is too integrated or too
frameworky then there is a perfect place to start fixing it ;) My concern
is that with two projects with identical purposes is going to cause a
little confusion. Worse yet I have a feeling that it may be possible that
the same issues/mistakes/problems that occur within Avalon will occur
within this project. I think Sam referred to Avalon as the eternal alpha
project (IIRC it has been around for about 3 years and is only starting to
stabilize recently).
Speaking for myself (and not for Avalon group) I would love to see a
flattening of CVS access and allow an area to develope and maintain these
different components within Avalon. I don't care about the politics of each
component - as long as they are labeled as STABLE/ALPHA/BETA/whatever and
stick to it.
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: [VOTE] Initial Proposal - Re: Consensus ?
Posted by cm...@yahoo.com.
> < http://husted.com/about/jakarta/lib005.htm >
>
> Since the vote on this sort-of evolved, I'm grandfathering these four
> +1's
>
> +1 Costin
Yes, you got me right !
Thanks for all the great work on mediating this, I'll be glad to see you
in the PMC.
> Also feel free to suggest a name for the subproject, if you think
> Library is too bland. Suggestions have been Agora, Rupert, and Zarf.
My preference would be Agora.
> Peter made a nice offer about merging this into Avalon, and maybe
> breaking it out later. It's a sound idea, but personally, I would lean
> toward starting this as a standalone subproject, so it would be easier
> to find (which is pretty much the point).
+1 on a separate project, it's better to start fresh and neutral to
existing projects. Later we can merge ( a goal is to get projects will
to merge common code with agora :-).
Costin
Re: [VOTE] Initial Proposal - Re: Consensus ?
Posted by cm...@yahoo.com.
> < http://husted.com/about/jakarta/lib005.htm >
>
> Since the vote on this sort-of evolved, I'm grandfathering these four
> +1's
>
> +1 Costin
Yes, you got me right !
Thanks for all the great work on mediating this, I'll be glad to see you
in the PMC.
> Also feel free to suggest a name for the subproject, if you think
> Library is too bland. Suggestions have been Agora, Rupert, and Zarf.
My preference would be Agora.
> Peter made a nice offer about merging this into Avalon, and maybe
> breaking it out later. It's a sound idea, but personally, I would lean
> toward starting this as a standalone subproject, so it would be easier
> to find (which is pretty much the point).
+1 on a separate project, it's better to start fresh and neutral to
existing projects. Later we can merge ( a goal is to get projects will
to merge common code with agora :-).
Costin