[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]
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: [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]
[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: [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
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: 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
Noel J. Bergman wrote: 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. Then there is no NEED for a sandbox. --- 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
On Sun, 2006-04-09 at 10:20 -0400, Andrew C. Oliver wrote: > 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
> 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
> * 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
On 4/9/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > > 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. > 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
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 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]
