RE: [VOTE] Jakarta Sandbox
Martin, Jakarta is Components Sandbox Things move from sandbox to components. That would be fine if there was a well-defined scope for the sandbox. Should be the same as the scope for Jakarta. Define that, and you may have your answer. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sat, 2006-04-08 at 00:48 -0400, Henri Yandell wrote: What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? My fault, I thought we'd had a long thread on this before so didn't do much explaining. The same as Commons Sandbox contains potential Commons components, Jakarta Sandbox would be much the same but contain potential Jakarta components. Maybe I'm jumping the gun. Call me ignorant but that sounds like the incubator without incubation process. If you want to know about sandboxes, ask the Turbine people. We have had quite a number. Stratum, Fulcrum (which finally picked up speed), flux, jyve, origami, you've named it. A sandbox without a defined process that either promotes a project to become a real Jakarta project or calls quits and closes it (and moves it into archives) will IMHO lead to a lot of dead stuff. Look at sourceforge. While I like the basic idea of open source running free, my experiences from Turbine show that it does not work without at least some control. So I vote -0. I don't really like the idea but I'm not deeply enough in the discussion to veto it. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote: Yes. A lot of things predate the incubator. I'm not opposed to say an HTTPD-sandbox for experimental HTTPD related stuff. I'm not opposed to a POI-sandbox (indeed we have one but call it scratchpad) for POI-related stuff. However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. the sandbox already exists. the management and supervision were entrusted to the commons sub-project. sub-projects have no formal existence. the scope of the sandbox is the same as the scope for jakarta. anything that is in scope for jakarta is in scope for sub-projects. code in other languages is pretty much out but nearly any subject is in scope. the only limits are imposed by the community itself. jakarta's scope is the problem but it's hard to fix for both historic and community reasons - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On 4/10/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote: Yes. A lot of things predate the incubator. I'm not opposed to say an HTTPD-sandbox for experimental HTTPD related stuff. I'm not opposed to a POI-sandbox (indeed we have one but call it scratchpad) for POI-related stuff. However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. the sandbox already exists. the management and supervision were entrusted to the commons sub-project. sub-projects have no formal existence. the scope of the sandbox is the same as the scope for jakarta. anything that is in scope for jakarta is in scope for sub-projects. code in other languages is pretty much out but nearly any subject is in scope. the only limits are imposed by the community itself. When something graduates from this Jakarta Sandbox, where does it go? Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta subproject. But Hen has claimed to want to morph Jakarta into a non-umbrella, and graduating to a new Jakarta subproject would be counter to that goal. On the other hand, if it graduates to somewhere outside of Jakarta, why is the sandbox inside of Jakarta? -- Martin Cooper jakarta's scope is the problem but it's hard to fix for both historic and community reasons - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Mon, 10 Apr 2006, Martin Cooper wrote: On 4/10/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote: Yes. A lot of things predate the incubator. I'm not opposed to say an HTTPD-sandbox for experimental HTTPD related stuff. I'm not opposed to a POI-sandbox (indeed we have one but call it scratchpad) for POI-related stuff. However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. the sandbox already exists. the management and supervision were entrusted to the commons sub-project. sub-projects have no formal existence. the scope of the sandbox is the same as the scope for jakarta. anything that is in scope for jakarta is in scope for sub-projects. code in other languages is pretty much out but nearly any subject is in scope. the only limits are imposed by the community itself. When something graduates from this Jakarta Sandbox, where does it go? Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta subproject. But Hen has claimed to want to morph Jakarta into a non-umbrella, and graduating to a new Jakarta subproject would be counter to that goal. On the other hand, if it graduates to somewhere outside of Jakarta, why is the sandbox inside of Jakarta? In my incoherent mind it's: Jakarta is Components Sandbox Things move from sandbox to components. Once there, they are arranged into groupings to smooth communication. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On 4/10/06, Henri Yandell [EMAIL PROTECTED] wrote: On Mon, 10 Apr 2006, Martin Cooper wrote: On 4/10/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote: Yes. A lot of things predate the incubator. I'm not opposed to say an HTTPD-sandbox for experimental HTTPD related stuff. I'm not opposed to a POI-sandbox (indeed we have one but call it scratchpad) for POI-related stuff. However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. the sandbox already exists. the management and supervision were entrusted to the commons sub-project. sub-projects have no formal existence. the scope of the sandbox is the same as the scope for jakarta. anything that is in scope for jakarta is in scope for sub-projects. code in other languages is pretty much out but nearly any subject is in scope. the only limits are imposed by the community itself. When something graduates from this Jakarta Sandbox, where does it go? Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta subproject. But Hen has claimed to want to morph Jakarta into a non-umbrella, and graduating to a new Jakarta subproject would be counter to that goal. On the other hand, if it graduates to somewhere outside of Jakarta, why is the sandbox inside of Jakarta? In my incoherent mind it's: Jakarta is Components Sandbox Things move from sandbox to components. Once there, they are arranged into groupings to smooth communication. That would be fine if there was a well-defined scope for the sandbox. As Andy and others have pointed out, there is no scope right now. That means that someone could start, say, a new servlet container, or an OSGi framework, or whatever, that would have no reasonable place as a Jakarta Component. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. Why on sourceforge - why not on our infrastructure? What the difference for you? You want every tiny (commons) library go through the incubator? ...or do you just don't want full projects sneak in through that sandbox? So far I don't understand why you are seeing this so problematic. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Tue, 11 Apr 2006, Torsten Curdt wrote: However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. Why on sourceforge - why not on our infrastructure? What the difference for you? You want every tiny (commons) library go through the incubator? ...or do you just don't want full projects sneak in through that sandbox? So far I don't understand why you are seeing this so problematic. I think I get it. * If the scope of Jakarta = anything in Java, then a Jakarta Sandbox is a terrifying prospect. * If the scope of Jakarta is refined, then a Jakarta Sandbox would not be a problem. I think it's a pretty fair point for people to have. Will start another email based on Jakarta's scope. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
Why? Do you need something to do? I have many unworked open source tasks that I could pass on. I'm happy to help you along on them. Seriously. Henri Yandell wrote: On Tue, 11 Apr 2006, Torsten Curdt wrote: However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. Why on sourceforge - why not on our infrastructure? What the difference for you? You want every tiny (commons) library go through the incubator? ...or do you just don't want full projects sneak in through that sandbox? So far I don't understand why you are seeing this so problematic. I think I get it. * If the scope of Jakarta = anything in Java, then a Jakarta Sandbox is a terrifying prospect. * If the scope of Jakarta is refined, then a Jakarta Sandbox would not be a problem. I think it's a pretty fair point for people to have. Will start another email based on Jakarta's scope. Hen - 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: [VOTE] Jakarta Sandbox
y On Sat, 8 Apr 2006, Andrew C. Oliver wrote: Henri Yandell wrote: On Sat, 8 Apr 2006, Andrew C. Oliver wrote: -1 on these points 1. There should not be an escape from the pain of the incubator. All new projects must go through the incubator and endure. Commons sandbox was created prior to the incubator. Nope, all new communities must go through the incubator, not all new projects (well, components). So basically if I call my project a component I don't have to go through the incubator just YOUR incubator. Nope, poor explanation on my part. Code created within the Apache community does not have to go through the incubator at all. The only bit component refers to is related to Martin's point - it describes Jakartas scope - or at least the scope that I think we're arriving at after years of subprojects becoming tlp. 3. -1 to the form of this proposal which seems overly coarse grained or not nearly detailed (I'm not sure which) Sounds about right - response so far suggests I need a lot more in the proposal - and it's probably better to go with the JLC vote next so the sandbox issue would be more obvious (things would be going from Commons Sandbox to JLC grouping). So far that seems like more commons mess. Thus far I've failed to see what makes it not more of the same (aka commons). The usual chestnut :) You say communities, I say community. Agreed, the JLC proposal is completely yet more commons mess. Why's the 'yet more' part of this negative? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sat, 8 Apr 2006, Nathan Bubna wrote: On 4/8/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: Henri Yandell wrote: On Sat, 8 Apr 2006, Andrew C. Oliver wrote: -1 on these points 1. There should not be an escape from the pain of the incubator. All new projects must go through the incubator and endure. Commons sandbox was created prior to the incubator. Nope, all new communities must go through the incubator, not all new projects (well, components). So basically if I call my project a component I don't have to go through the incubator just YOUR incubator. Basically misery loves company so I think if the same sin buys me purgatory, I'd like to see you there. Even if you call your project a component. So, if i have an idea for a new group of code (avoiding component vs project terminology for the moment) that would reasonably fit within the jakarta mission (whatever you think that might be), you think i should have to go through the incubator to start developing it? sounds like a great plan to shut down innovation from within the jakarta community or else force it to go underground and hide out within existing groups of code. maybe i'm wrong on this, but i always understood the incubation process to be for bringing in outside groups-of-code/communities-of-developers into the ASF.If some Jakarta developers want to try and start a new group-of-code that would fit in Jakarta, a sandbox seems like a great place to play around with it and develop interest. If, on the other hand, i've been developing some group-of-code over at sourceforge, with oversight and community happening there, and at some later point i want to bring that into Jakarta, then incubation makes perfect sense to me. +1, exactly how I understand it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sat, 2006-04-08 at 00:51 -0400, Henri Yandell wrote: On Sat, 8 Apr 2006, Simon Kitching wrote: And who is expected to subscribe to [EMAIL PROTECTED] Those who want to? :) I imagine those working on sandbox components at the moment, plus a handful of people who tend to subscribe to such lists. Out of interest - if we take a list with N mails a day, and have 2 lists with N/2 mails a day, is that something you'd view as more painful or the same amount of pain? I know that when subscribing to Jakarta subprojects I'm not interested in as a coder, I subscribe to both the -user and -dev and funnel them both into the same folder. For my level of interest it's just [EMAIL PROTECTED], not ecs-xxx@ etc. So I'm probably answering more pain to the above, but I've got a simple solution that hides the minor pain increase. I'm more concerned about the other direction - a lack of people watching this new sandbox. Currently, all commons developers are subscribed to commons-dev, and therefore get to see sandbox stuff. Ok, it's sometimes a little annoying. However it does mean that we're all aware of what's going on at a general level. Commits including non-ASF copyright statements are going to be picked up for example, as are commits of jarfiles. Help/comments are also often offered by committers not specifically working on that sandbox project. I'm worried that if the sandbox becomes its own world, then it will end up with very few subscribers, and that good projects will therefore have a hard time becoming a success. Ideally, a sandbox project should be adopted by its closest living relative, and use that project's list until it grows up. This [EMAIL PROTECTED] idea looks more like a communal orphanage to me... Of course if a big bunch of people volunteer to join this proposed sandbox community then that would resolve my concerns. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
So basically if I call my project a component I don't have to go through the incubator just YOUR incubator. Nope, poor explanation on my part. Code created within the Apache community does not have to go through the incubator at all. The only bit component refers to is related to Martin's point - it describes Jakartas scope - or at least the scope that I think we're arriving at after years of subprojects becoming tlp. Not everyone is at your destination. Nor does everyone agree on the direction. Totally NOT how the incubator was described to me. As I understand it if Tomcat (for instance) wants to create a new JSP engine, that's kosher for Tomcat. However if someone in POI wanted to create a new AI engine (having nothing to do with MS file formats) then that is Incubator-toast. 3. -1 to the form of this proposal which seems overly coarse grained or not nearly detailed (I'm not sure which) Sounds about right - response so far suggests I need a lot more in the proposal - and it's probably better to go with the JLC vote next so the sandbox issue would be more obvious (things would be going from Commons Sandbox to JLC grouping). So far that seems like more commons mess. Thus far I've failed to see what makes it not more of the same (aka commons). The usual chestnut :) You say communities, I say community. I said nothing of the sort either way. I have come to consider such discussions in the same thread as proactively actuate our SOA realization strategy paradigm shift... Lets focus on core and concrete. Agreed, the JLC proposal is completely yet more commons mess. Why's the 'yet more' part of this negative? I would challenge that the problem with the commons mess is it has no scope what-so-ever -- except kinda java...or not really... And now somehow the Ant has designed to swallow the elephant. -1 to that. No more predominantly scopeless or fuzzy-scope commons-like-projects. No more painless ways around the incubator. Not because I love the incubator, I think it was a bad idea, but it should apply to everyone. I think HTTPClient has a scope (for instance) and that's probably even tight. I don't think commons has ANY scope other than what the participants have decided to do today. If you want to talk the board's intent -- then this is the core of the issue and not whether you force us all to get 1000 irrelevant-to-us emails in a day. -andy Hen - 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: [VOTE] Jakarta Sandbox
On 4/9/06, Simon Kitching [EMAIL PROTECTED] wrote: snip/ Ideally, a sandbox project should be adopted by its closest living relative, and use that project's list until it grows up. This [EMAIL PROTECTED] idea looks more like a communal orphanage to me... Of course if a big bunch of people volunteer to join this proposed sandbox community then that would resolve my concerns. snap/ This is where the prior discussion thread stalled in my mind: adoption and visibility. Having worked on code in both Taglibs and Commons sandboxes recently, IMO, anything that can give these projects greater Jakarta visibility is good since quite a few projects/components in the existing sandboxes [1],[2] are looking for developer support. It remains to be seen whether the new SVN auth will help here. -Rahul [1] http://jakarta.apache.org/commons/sandbox/ [2] http://jakarta.apache.org/taglibs/ (see nav bar) Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Jakarta Sandbox
* Create development mailing list ([EMAIL PROTECTED]) sandbox-dev@ ? Otherwise, fine. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Jakarta Sandbox
1. There should not be an escape from the pain of the incubator. All new projects must go through the incubator and endure. ACO's gratuitously snarky comments aside, projects coming into the ASF go through the Incubator. New things started entirely within the ASF do not, currently. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sun, 2006-04-09 at 10:20 -0400, Andrew C. Oliver wrote: snip Totally NOT how the incubator was described to me. As I understand it if Tomcat (for instance) wants to create a new JSP engine, that's kosher for Tomcat. However if someone in POI wanted to create a new AI engine (having nothing to do with MS file formats) then that is Incubator-toast. that is a matter of scope, not incubation policy a hypothetical example might help to illustrate the difference: JSP engines are in-scope for tomcat but out-of-scope for xerces. xerces is not allowed a JSP engine as part of that project. but if a new JSP engine wanted by tomcat was created outside the ASF, it would need to come in through the incubator. if it arrives without a external community (for example, because it was developed off-shore by tomcat developers) then it's a simply process of legal sign off. if it arrives with a community then it needs to enter as a podling to ensure that the community gets the help they need to understand how apache works. however, if the xerces developers (let's say for sake of argument) wanted to create a JCP engine at apache but outside tomcat they would need to create a new project. it is now seems more difficult for new projects to be created at apache (the test is subjective and democratic so this is an observation not a rule). it is much easier to create a new project offshore and then bring it in through the incubator. so, the scope issue would (for practical purposes) probably require them to go through the incubator. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
Based on that what WOULD BE out of scope of today's commons or this MEGA-sandbox or this JCL or whatever? robert burrell donkin wrote: On Sun, 2006-04-09 at 10:20 -0400, Andrew C. Oliver wrote: snip Totally NOT how the incubator was described to me. As I understand it if Tomcat (for instance) wants to create a new JSP engine, that's kosher for Tomcat. However if someone in POI wanted to create a new AI engine (having nothing to do with MS file formats) then that is Incubator-toast. that is a matter of scope, not incubation policy a hypothetical example might help to illustrate the difference: JSP engines are in-scope for tomcat but out-of-scope for xerces. xerces is not allowed a JSP engine as part of that project. but if a new JSP engine wanted by tomcat was created outside the ASF, it would need to come in through the incubator. if it arrives without a external community (for example, because it was developed off-shore by tomcat developers) then it's a simply process of legal sign off. if it arrives with a community then it needs to enter as a podling to ensure that the community gets the help they need to understand how apache works. however, if the xerces developers (let's say for sake of argument) wanted to create a JCP engine at apache but outside tomcat they would need to create a new project. it is now seems more difficult for new projects to be created at apache (the test is subjective and democratic so this is an observation not a rule). it is much easier to create a new project offshore and then bring it in through the incubator. so, the scope issue would (for practical purposes) probably require them to go through the incubator. - robert - 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: [VOTE] Jakarta Sandbox
Andrew C. Oliver wrote: Noel J. Bergman wrote: projects coming into the ASF go through the Incubator. New things started entirely within the ASF do not, currently. Then there is no NEED for a sandbox. As you know, the sandbox predates the Incubator, and AIUI, the Sandbox exists so as to allow experiments without polluting the respository in such manner that would confuse the public and ourselves about what is real and what is play. There may be other ways in to achieve that goal. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
Yes. A lot of things predate the incubator. I'm not opposed to say an HTTPD-sandbox for experimental HTTPD related stuff. I'm not opposed to a POI-sandbox (indeed we have one but call it scratchpad) for POI-related stuff. However Jakarta-sandbox is SCOPELESS. Go have a scopeless sandbox on sourceforge IMO. If you want to start a whole NEW project then do that in the incubator IMO. Noel J. Bergman wrote: Andrew C. Oliver wrote: Noel J. Bergman wrote: projects coming into the ASF go through the Incubator. New things started entirely within the ASF do not, currently. Then there is no NEED for a sandbox. As you know, the sandbox predates the Incubator, and AIUI, the Sandbox exists so as to allow experiments without polluting the respository in such manner that would confuse the public and ourselves about what is real and what is play. There may be other ways in to achieve that goal. --- Noel - 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: [VOTE] Jakarta Sandbox
-1 on these points 1. There should not be an escape from the pain of the incubator. All new projects must go through the incubator and endure. Commons sandbox was created prior to the incubator. 2. No to [EMAIL PROTECTED] if it is a MEGA-list for all of Jakarta. The commons list is horrible and I get enough email. There is no technical advantage to one mega list for all software. Most problems are NOT oversite problems/discussions. 3. -1 to the form of this proposal which seems overly coarse grained or not nearly detailed (I'm not sure which) -Andy Henri Yandell wrote: On Sat, 8 Apr 2006, Simon Kitching wrote: On Fri, 2006-04-07 at 16:28 -0700, Martin Cooper wrote: On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? And who is expected to subscribe to [EMAIL PROTECTED] Those who want to? :) I imagine those working on sandbox components at the moment, plus a handful of people who tend to subscribe to such lists. Out of interest - if we take a list with N mails a day, and have 2 lists with N/2 mails a day, is that something you'd view as more painful or the same amount of pain? I know that when subscribing to Jakarta subprojects I'm not interested in as a coder, I subscribe to both the -user and -dev and funnel them both into the same folder. For my level of interest it's just [EMAIL PROTECTED], not ecs-xxx@ etc. So I'm probably answering more pain to the above, but I've got a simple solution that hides the minor pain increase. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
Am Freitag, den 07.04.2006, 19:17 -0400 schrieb Henri Yandell: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. [ ] +1 [X] -1 I vote -1 because I do not want my mailbox to be flooded with piles of mails about stuff I don't care about. I'd like to solicit only those pieces I am interested in. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Public key fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E signature.asc Description: This is a digitally signed message part
Re: [VOTE] Jakarta Sandbox
On Sat, 8 Apr 2006, Andrew C. Oliver wrote: -1 on these points 1. There should not be an escape from the pain of the incubator. All new projects must go through the incubator and endure. Commons sandbox was created prior to the incubator. Nope, all new communities must go through the incubator, not all new projects (well, components). 2. No to [EMAIL PROTECTED] if it is a MEGA-list for all of Jakarta. The commons list is horrible and I get enough email. There is no technical advantage to one mega list for all software. Most problems are NOT oversite problems/discussions. Is it the naming? How about [EMAIL PROTECTED] Are you suggesting that there should be a mailing list per component in the sandbox? [EMAIL PROTECTED], [EMAIL PROTECTED] etc? dev@ was in Stephen's original proposal on Commons - so not something I'm personally tied to. It's not tied to my 'one-community' mantra, though I suspect it might appear that way :) 3. -1 to the form of this proposal which seems overly coarse grained or not nearly detailed (I'm not sure which) Sounds about right - response so far suggests I need a lot more in the proposal - and it's probably better to go with the JLC vote next so the sandbox issue would be more obvious (things would be going from Commons Sandbox to JLC grouping). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sat, 8 Apr 2006, Rainer Klute wrote: Am Freitag, den 07.04.2006, 19:17 -0400 schrieb Henri Yandell: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. [ ] +1 [X] -1 I vote -1 because I do not want my mailbox to be flooded with piles of mails about stuff I don't care about. I'd like to solicit only those pieces I am interested in. That's why it didn't say general@ :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On 4/8/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: Henri Yandell wrote: On Sat, 8 Apr 2006, Andrew C. Oliver wrote: -1 on these points 1. There should not be an escape from the pain of the incubator. All new projects must go through the incubator and endure. Commons sandbox was created prior to the incubator. Nope, all new communities must go through the incubator, not all new projects (well, components). So basically if I call my project a component I don't have to go through the incubator just YOUR incubator. Basically misery loves company so I think if the same sin buys me purgatory, I'd like to see you there. Even if you call your project a component. So, if i have an idea for a new group of code (avoiding component vs project terminology for the moment) that would reasonably fit within the jakarta mission (whatever you think that might be), you think i should have to go through the incubator to start developing it? sounds like a great plan to shut down innovation from within the jakarta community or else force it to go underground and hide out within existing groups of code. maybe i'm wrong on this, but i always understood the incubation process to be for bringing in outside groups-of-code/communities-of-developers into the ASF.If some Jakarta developers want to try and start a new group-of-code that would fit in Jakarta, a sandbox seems like a great place to play around with it and develop interest. If, on the other hand, i've been developing some group-of-code over at sourceforge, with oversight and community happening there, and at some later point i want to bring that into Jakarta, then incubation makes perfect sense to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? [ ] +1 [X] -1 This just seems like too big of a can of worms to me. -- Martin Cooper Vote to last no shorter than a week. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Fri, 2006-04-07 at 16:28 -0700, Martin Cooper wrote: On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? And who is expected to subscribe to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Fri, 7 Apr 2006, Martin Cooper wrote: On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? My fault, I thought we'd had a long thread on this before so didn't do much explaining. The same as Commons Sandbox contains potential Commons components, Jakarta Sandbox would be much the same but contain potential Jakarta components. Maybe I'm jumping the gun. One of the reasons this was brought up again in last months naval introspection threads was that if we have a Jakarta Language Components grouping (ie: part of Commons moves out), then the Commons sandbox would no longer be applicable. Plus it allows us to bring the Taglibs sandbox plus it gives us a nice home for the Taglibs sandbox to be dormantized to. [ ] +1 [X] -1 This just seems like too big of a can of worms to me. It's the same can of worms as Jakarta as a whole, so I'm not sure if we can view this as being worrisome and the general scope of Jakarta as not worrisome. I'm probably jumping the gun - next vote maybe should have been to have restricted the scope of Jakarta rather than promote the sandbox up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On Sat, 8 Apr 2006, Simon Kitching wrote: On Fri, 2006-04-07 at 16:28 -0700, Martin Cooper wrote: On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote: Calling a vote to create a Jakarta Sandbox; which entails: * Move Jakarta Commons Sandbox to Jakarta Sandbox * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox * Create development mailing list ([EMAIL PROTECTED]) * Create wiki (and migrate wiki bits from j-c-s/j-t-s) * Jakarta Sandbox to initially use the Commons sandbox processes. What would be the constraints on what could go in there? Anything, as long as it's written in or for Java? And who is expected to subscribe to [EMAIL PROTECTED] Those who want to? :) I imagine those working on sandbox components at the moment, plus a handful of people who tend to subscribe to such lists. Out of interest - if we take a list with N mails a day, and have 2 lists with N/2 mails a day, is that something you'd view as more painful or the same amount of pain? I know that when subscribing to Jakarta subprojects I'm not interested in as a coder, I subscribe to both the -user and -dev and funnel them both into the same folder. For my level of interest it's just [EMAIL PROTECTED], not ecs-xxx@ etc. So I'm probably answering more pain to the above, but I've got a simple solution that hides the minor pain increase. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
