>(0) Do you agree with the "consensus points" above?
+1
>(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?
I guess I imagined that the jakarta-library subproject (whatever we're
calling it now) would have it's own set of committers, each of whom can
commit changes to any component/module in the library subproject, much like
jakarta-tablibs, I think.
In practice, this would be simliar to the second alternative above, since
that's where the committers and codebases would largely be coming from.
The first alternative would generally be the case anyway by the rules of
etiquette alone, but with more committers, we have greater economy of scale
right? Why would we want to fragment it down to the component level
(committers for sub-sub-projects)?
>(2)
>
>Who will approve adding new codebases to the project:
>
>All the Committers?
>
+1. Here I'm reading "all the committers" as all the committers in the
jakarta-library project, as described above. Simple majority of votes or
Ted's (I think) suggestion of super-majority (2/3?) both have their appeal.
>(3)
>
>Is overlap between components acceptable? Is it OK for two components to
>solve the same problem differently?
Absolutely. Community momementum will should keep the number of active
components that solve the same problem close to 1, but will also identify
when two solutions to what seems to be the same problem are necessary.
>(4)
>
>Do we need a set of super-committers (e.g. PMC members) who can step-up
>when a codebase loses a sole Committer.
If we follow my suggestion to #1, then this role should be covered by the
other committers to jakarta-lib.
>(5)
>
>Can the unit of reuse and release be the package?
>
>OR,
>
>Will we need a larger or smaller "granule" for each codebase?
As an axiom, unit of release == unit of reuse. At first blush, a single(or
set of nested) Java package would seem to work for that, but I'm not sure we
really need a consensus on this point, do we?
>(6)
>
>Should we encourage giving components boring, functional names, to
>emphasize their utilitarian nature?
If we give them boring, functional names, then what happens when you want
two approaches to the same functional problem?
As I said before, I think putting the interesting name under a package
giving the boring functional name would work:
+ *.widget or *.widget.interface -- defines the shared interface, if any, or
the "reference" implementation, if any
+ *.widget.tiger -- a specific implementation of the widget functionality
+ *.widget.cheetah -- another implementation of the widget functionality
>(7)
>
>Start with a pilot Jakarta subproject, and then consider proposing a new
>ASF Project if it works.
+1, I think. Whatever the path of least resistance is at this point. Let's
get going.
- rod <rwaldhof at us.britannica.com>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
