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]
[Jakarta Wiki] Update of JakartaBoardReport-June2006 by FelipeLeme
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by FelipeLeme: http://wiki.apache.org/jakarta/JakartaBoardReport-June2006 The comment on the change is: FIxed Cactus version - thanks Dennis for pointing it out... -- === Releases === - Cactus 1.17.2 was released on March 26th, 2006. + Cactus 1.7.2 was released on March 26th, 2006. === Community changes === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of JakartaBoardReport-June2006 by FelipeLeme
You're right - good catch! Dennis Lundberg wrote: Cactus 1.17.2 was released on March 26th, 2006. Shouldn't that be 1.7.2? - 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]
[Jakarta Wiki] Update of JakartaBoardReport-June2006 by SandyMcArthur
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by SandyMcArthur: http://wiki.apache.org/jakarta/JakartaBoardReport-June2006 The comment on the change is: added blurb about pool 1.3 release -- === Releases === - Cactus 1.7.2 was released on March 26th, 2006. + * Cactus 1.7.2 was released on March 26th, 2006. + * Commons Pool 1.3 was released on April 3rd 2006. === Community changes === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
