On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > 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?
One of your big things right now - order and organisation. ;-) 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. > 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? 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. * Independent packages. * Intended for server-side. * Not frameworks. 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. -- Martin Cooper Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
