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
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 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
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. 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] clears point 2 but does nothing for one. The name dev certainly implies something that you say you do not intend. 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 :) Booo. 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). -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, 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 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
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
-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]
