On Sun, 5 Mar 2006, Martin Cooper wrote:
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
I notice that Commons and HTTP Components both have charters. Other
subprojects may have them and I've just missed in my very quick look.
Do these serve any purpose? Are they a legacy of the days when we tried to
create an ASF-like structure within Jakarta to organize things?
They were originally created to define the (sub)projects we were creating,
and they still serve that purpose. If you get rid of the charter, where
would you propose that we define the purpose and scope of these projects?
And what would you call that if it isn't a charter?
Any reason not to go ahead and kill these subproject charters?
Yes. See above. There needs to be some place where we state the "official"
purpose and scope, and that isn't just some words that someone happened to
use as a description on some page that's part of the site.
Why restrict a project?
I missed the alternative on this email (it spun out of a Commons email)
which is why don't we require these of all subprojects?
Say some Prolog constraint framework decided it wanted to be part of
Commons. Where would you point them to explain that that's not what Commons
is about?
The Jakarta charter where it says Java (which in fact it doesn't say -
might be a bit of an ommission).
Here's the Commons Charter:
***************************************
0) rationale
<history, then:>
A Jakarta subproject to solely create and maintain
independent packages is proposed to accelerate and guide this process.
(1) scope of the subproject
The subproject shall create and maintain packages written in the Java
language, intended for use in server-related development, and designed to
be used independently of any larger product or framework. Each package
will be managed in the same manner as a larger Jakarta product.
<bit about sandbox>
(2) identify the initial set of committers
<historical list>
******************************************
If anything, that's a better Jakarta charter than the Jakarta charter and
should be merged in - but there's very little to restrict the scope of
Commons.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
