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 < [EMAIL PROTECTED] >
> Rodney Waldhoff < [EMAIL PROTECTED] >
> Ignacio J. Ortega < [EMAIL PROTECTED] >
> Bhamidi Krishna < [EMAIL PROTECTED] >
> Geir Magnusson Jr. < [EMAIL PROTECTED] >
> Ted Husted < [EMAIL PROTECTED] >
> Federico Barbieri < [EMAIL PROTECTED] >
> Peter Donald < [EMAIL PROTECTED] >
> Ceki < [EMAIL PROTECTED] >
> Morgan Delagrange < [EMAIL PROTECTED] >
>
> -Ted.
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
