On Sun, 5 Mar 2006, Martin Cooper wrote:
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
Why restrict a project?
One of your big things right now - order and organisation. ;-)
Guess I don't see this as one that needs constraining - how a
component/subproject does something - sure. What it's allowed to do -
nope. Not as long as it falls within the larger Jakarta charter.
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?
I can't answer the question, but that would be fine with me.
Seems like unnecessary bureaucracy.
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).
OK, then what about a Java constraint framework?
If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons,
+1 to Jakarta, but they're converging to both be a +1 if not too framework
like.
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.
Well, I see:
* Written in Java.
+1 to this in the Jakarta charter - though I'd probably say 'Written for
Java'. Commons Daemon has C parts, but exists for the purposes of Java.
* Independent packages.
Common sense - assuming it means other people wouldn't use their packages,
but fine to add to the Jakarta charter. If it means no dependencies, well
we break this one a lot.
* Intended for server-side.
+1 to this in the Jakarta charter. We've always had this as a loose
constraint. We don't interpret this as server-side though, rather we
interpret it as not client-side.
* Not frameworks.
+1 to this in the Jakarta charter - we're heading that way.
Those don't all apply to Jakarta as a whole, but they do all apply to
Commons, and I, for one, do not want to lose those statements of scope and
purpose. It's a charter, whether or not you want to call it one.
So my disagreement is that I think it should apply to Jakarta as a whole -
and is pretty close to doing so.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
