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. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
