>From: Ted Husted <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: [POLL] - General Consensus, Round 1
>Date: Sat, 17 Feb 2001 07:24:24 -0500
>
>Now that we have a proposed set of committers and codebases, I believe
>the next step is to agree upon a working infrastructure. We could then
>draw up a proposal, and maybe a prototype Web site.
>
>Going over the past posts, I believe we have a consensus on these
>points:
>
>-----
>
>* Each component must be something that can be used by one or more ASF
>products.
>
>* Each component must have a clearly defined purpose, scope, and API.
>(Do one thing well, and keep your contracts!)
>
>* Each component should clearly specify any external API dependencies,
>including JDK version required.
>
>* External dependencies on optional and third-party APIs should be
>minimized.
>
>* The components should provide Ant build files as part of the standard
>distribution.
>
>* The components should use XML format files for configuration options.
>
>* When applicable, optional JavaBean wrappers around a component are
>encouraged.
>
>* Each component will be featured on its own page on the subproject Web
>site, which may then be indexed in a master catalog.
>
>* The subproject may also host a top-level "general" and "announcement"
>mailing list.
>
>* The subproject may also provide a single JAR of all stable component
>releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
>
>-----
>
>Of course, if you disagree with any of these points, please say so now
>(see below). Only committers' votes count, but every committer's vote
>counts!
>
>Following are some additional questions where I was less certain of how
>people feel. Of course, if anyone has similar questions of their own,
>please post them or start a discussion leading to a poll.
>
>Please respond to one alternative in each block (or suggest another
>alternative):
>
>(0) +1
>
>Do you agree with the "consensus points" above?
>
>(1)
>
>Should the the components be created and maintained as individual
>subproducts by a set of "component committers"?
>
>OR,
>
>Should the component be created and maintained by the union of all
>interested committers from the Jakarta products that are using the
>component?
A set of committers from the commiters should maintain it.
>
>(2)
>
>Who will approve adding new codebases to the project:
>
>All the Committers?
>
>OR,
>
>A group of "core" Committers?
>
>OR,
>
>Any Jakarta committer can add a codebase, SourceForge style.
A group of core committers should be feasible, otherwise communication and
reply time may be too high and infeasible.
>
>(2)
>
>Is overlap between components acceptable? Is it OK for two components to
>solve the same problem differently?
Overlap should be avoided as far as possible.
>(3)
>
>Do we need a set of super-committers (e.g. PMC members) who can step-up
>when a codebase loses a sole Committer.
We need to have a backup in case of any emergiencies.
>(4)
>
>Can the unit of reuse and release be the package?
>
>OR,
>
>Will we need a larger or smaller "granule" for each codebase?
>
We should decide a set of "functional parameters" before starting the
package.
>(5)
>
>Should we encourage giving components boring, functional names, to
>emphasize their utilitarian nature?
As is the consensus. I have no problems with any name.
>(6)
>
>Do we want to propose this as a Jakarta subproject?
>
>OR,
>
>Do we want to propose a new PMC that would focus on Java development
>tools
>(Ant and a package/component library -- maybe BSF too)?
>
>OR,
>
>Start with a pilot Jakarta subproject, and then consider proposing a new
>ASF Project if it works.
Start with a pilot project and propose a new ASF if it works.
>
>-----
>
>I will also soon move < http://husted.com/jakarta/library.html > to the
>Jakarta Web site. (But, hey, its the weekend, the kids are all slept
>over at friends ;-).
>
>-T.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
