Re: Subproject Charters
On Sun, 2006-03-05 at 17:31 -0500, Henri Yandell wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: 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: snip 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. I specifically chose a framework for my example because we have long stated that frameworks should not live in Commons, and that is stated in our charter. Are you saying you want to change that now, to allow frameworks as Commons components? I so, -1 from me. Other way, frameworks -1 to being within Jakarta. Depends on definition of framework - VFS is a framework to me; an interface structure designed for multiple implementations. I'd stay +1 for small things like VFS. IMO VFS is a bridging library, not a framework. bridging libraries have a simple, user facing API is intended to be used as a standard library. they also have a SPI (typically a mini-framework) to allow the library to be extended by adding new implementations. normal users should never use this: they just use it as a normal library. there are actually a number of bridging APIs in the commons and some more are in the sandbox (for example, proxy). they are small and useful for library creators since they allow projects to support multiple backend configurations. bridging APIs have a number of similarities and would probably make sense as a grouping. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subproject Charters
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? Any reason not to go ahead and kill these subproject charters? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
Hola, 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? I think the answer to the 2nd question is yes. Any reason not to go ahead and kill these subproject charters? The Commons is about having a place for existing committers to easily and quickly play with stuff that may or may not become actual ASF projects. If we kill the Commons charter, we either need to make sure an alternative place is available for that purpose, or that all members agree to take their playing elsewhere, e.g. SourceForge. -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On 05/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, 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? I think the answer to the 2nd question is yes. Or they may be a way of trying to avoid feature creep. Any reason not to go ahead and kill these subproject charters? The Commons is about having a place for existing committers to easily and quickly play with stuff that may or may not become actual ASF projects. If we kill the Commons charter, we either need to make sure an alternative place is available for that purpose, or that all members agree to take their playing elsewhere, e.g. SourceForge. ?? did you mean Sandbox - or the whole of Commons ?? -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
Hola, ?? did you mean Sandbox - or the whole of Commons ?? Sandbox, and apologies for the confusion. Sometimes things are so crystal clear in one's mind, and yet different stuff gets typed out ;) -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
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. 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? -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
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]
Re: Subproject Charters
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]
Re: Subproject Charters
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]
Re: Subproject Charters
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: 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. It's not so much what it's allowed to do, as much as to define its purpose. Perhaps you see Velocity as a viable Commons component, but I don't. Nor do I think it would make sense for Digester to be part of Cactus, or Taglibs to be part of Slide. A well-defined scope is a good thing, and helps people understand what they're looking at. 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. It's not bureaucracy. See above. 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. I specifically chose a framework for my example because we have long stated that frameworks should not live in Commons, and that is stated in our charter. Are you saying you want to change that now, to allow frameworks as Commons components? I so, -1 from me. -- Martin Cooper 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]
