Re: [POLL] Future Of Turbine-JCS
On Dec 15, 2003, at 4:23 PM, robert burrell donkin wrote: On 13 Dec 2003, at 22:22, Martin Poeschl wrote: what do you mean? the code works. it is used by other projects .. and basically development slowed down as the developers are waiting for the jcache spec ... so i don't think there is any problem as long as there are developers maintaining the code IMHO 1 the pmc is unable to demonstrate oversight. 2 there are a large number of pmc people who believe that umbrella sub-projects don't work. as far as i was concerned the consensus was that whatever the JCS team wanted was cool provided that it addressed 1 + 2. promotion to sub-project status satisfies 2 and having henning and other turbineers volunteer to provide oversight satisfies 1. If you solve 1, then 2 can be demonstrated. No need to do anything but ensure PMC oversight. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 13 Dec 2003, at 22:22, Martin Poeschl wrote: robert burrell donkin wrote: On 12 Dec 2003, at 09:28, Henning Schmiedehausen wrote: On Thu, 2003-12-11 at 21:07, robert burrell donkin wrote: hi henning you don't need to be a committer to act as a mentor. from what i've heard, i'd say that you'd be an ideal candidate :) Hi, thanks. :-) I'm willing to subscribe to JCS for watching the developers there and help them getting out a release. We should try to get genuine interest from their side to push JCS ahead. it'll either have to go forward or go back. the pmc can't really allow it to drift any more. if there isn't any activity then we'll reluctantly have to think about taking action. what do you mean? the code works. it is used by other projects .. and basically development slowed down as the developers are waiting for the jcache spec ... so i don't think there is any problem as long as there are developers maintaining the code IMHO 1 the pmc is unable to demonstrate oversight. 2 there are a large number of pmc people who believe that umbrella sub-projects don't work. as far as i was concerned the consensus was that whatever the JCS team wanted was cool provided that it addressed 1 + 2. promotion to sub-project status satisfies 2 and having henning and other turbineers volunteer to provide oversight satisfies 1. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
robert burrell donkin wrote: On 12 Dec 2003, at 09:28, Henning Schmiedehausen wrote: On Thu, 2003-12-11 at 21:07, robert burrell donkin wrote: hi henning you don't need to be a committer to act as a mentor. from what i've heard, i'd say that you'd be an ideal candidate :) Hi, thanks. :-) I'm willing to subscribe to JCS for watching the developers there and help them getting out a release. We should try to get genuine interest from their side to push JCS ahead. it'll either have to go forward or go back. the pmc can't really allow it to drift any more. if there isn't any activity then we'll reluctantly have to think about taking action. what do you mean? the code works. it is used by other projects .. and basically development slowed down as the developers are waiting for the jcache spec ... so i don't think there is any problem as long as there are developers maintaining the code Just as you I'm currently spread out between a few hats but I'll try to squeeze in some time to help here. great :) i know that i've been pushing very, very hard recently but i really have the new year in my mind as a significant landmark. i'd really like to be able to face the new year with the major fundamental issues basically fixed. i'm certainly no willing to continue to be this stretched for much longer. i'm hoping that the current period is just a transitionary phase. i've been worried about oversight of turbine for some time (and i know some other people have as well) but JCS seems like it's the only real issue left (providing that turbineers are willing to serve on the pmc). if possible i'd like to see if we can't some kind of release (0.9?) out very soon and then push for promotion very soon in the new year. +1 martin - 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: [POLL] Future Of Turbine-JCS
On 12 Dec 2003, at 09:28, Henning Schmiedehausen wrote: On Thu, 2003-12-11 at 21:07, robert burrell donkin wrote: hi henning you don't need to be a committer to act as a mentor. from what i've heard, i'd say that you'd be an ideal candidate :) Hi, thanks. :-) I'm willing to subscribe to JCS for watching the developers there and help them getting out a release. We should try to get genuine interest from their side to push JCS ahead. it'll either have to go forward or go back. the pmc can't really allow it to drift any more. if there isn't any activity then we'll reluctantly have to think about taking action. Just as you I'm currently spread out between a few hats but I'll try to squeeze in some time to help here. great :) i know that i've been pushing very, very hard recently but i really have the new year in my mind as a significant landmark. i'd really like to be able to face the new year with the major fundamental issues basically fixed. i'm certainly no willing to continue to be this stretched for much longer. i'm hoping that the current period is just a transitionary phase. i've been worried about oversight of turbine for some time (and i know some other people have as well) but JCS seems like it's the only real issue left (providing that turbineers are willing to serve on the pmc). if possible i'd like to see if we can't some kind of release (0.9?) out very soon and then push for promotion very soon in the new year. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Thu, 2003-12-11 at 21:07, robert burrell donkin wrote: > hi henning > > you don't need to be a committer to act as a mentor. from what i've > heard, i'd say that you'd be an ideal candidate :) Hi, thanks. :-) I'm willing to subscribe to JCS for watching the developers there and help them getting out a release. We should try to get genuine interest from their side to push JCS ahead. Just as you I'm currently spread out between a few hats but I'll try to squeeze in some time to help here. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire "Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen." -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
hi henning you don't need to be a committer to act as a mentor. from what i've heard, i'd say that you'd be an ideal candidate :) we need more eyes on more lists. what worries folks (including myself) is that there aren't really very many pmc eyes on the JCS list. this means that there's no one there either to provide oversight and to keep them on the straight and narrow - but also there's no one there to point them in the right direction when it comes to issues like release management and current ASF policies or to help with stuff. there's also quite a large chance that we'll have to restrict binding votes to pmc members only (sad, but true) sometime soonish. in this case, JCS will need three pmc members on list to validate votes. i'd rather think ahead and have enough pmc people watching the list than have JCS stall just as it might be turning round. i'm willing (as a last resort) to take on this roll (if no one else volunteers) but i'm currently averaging 300 emails a day and i'm spread very thin now trying to do something similar for the other poorly represented jakarta sub-projects. i really want to start coding again so i'd really appreciate it if some other people would step up to take up this role for JCS. - robert On 10 Dec 2003, at 08:51, Henning Schmiedehausen wrote: I'd do it, but I'm not personally involved in JCS. IMHO Martin Poeschl (who is a Turbineer _and_ works with JCS) would be perfect but I know that he will be on holidays for a longer time (either already is or will be soon. Martin?). Martin did the Turbine 2.2 release and most of the Torque releases in the past and I did the 2.3 release of Turbine, so this might count as "release management experience". ;-) Regards Henning On Tue, 2003-12-09 at 13:13, robert burrell donkin wrote: in this case, i'd say we'll need sufficient volunteers from the jakarta pmc to ensure oversight during this period. it'd probably be good if they were turbineers and if at least one had recent experience of release management. anyone willing to step up? - robert On 8 Dec 2003, at 15:28, Aaron Smuts wrote: Sounds good. Less disruption on the way to a release would be best. Aaron -Original Message- From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 3:22 AM To: Jakarta General List Subject: Re: [POLL] Future Of Turbine-JCS IMHO too complex. If there is already a JCS list (is there? As you can see, I'm a Turbine committer but I have zero overlap with JCS. In fact I didn't even know that this is a "turbine sub-sub project" for quite some time ;-) ), let's keep it. We want to build community? Let's _not_ fold it into the commons list where a completely different culture exists compared to a "normal" project list. I'm pretty sure that this will scare JCS users away. I'm thinking that "making it a direct Jakarta sub project" starts to make more and more sense. I'd propose that we move JCS in this direction, if the JCS developers push for a 1.0 release inside turbine-jcs and we make the transition into a Jakarta project with this 1.0 release (which would IMHO a fine reason to do so). Regards Henning On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). the way that i'd like to see a potential drop working is by folding the jcs user and development lists into the commons lists first. this would allow the rest of the commons to provide oversight. next, the JCS team should push towards some kind of release for the core engine (even if it's a 0.1 version). once this is ready, we'd update the commons website and officially add JCS to the commons. hopefully this would provide enough momentum to bootstrap a community and to create releases for all the various JCS bits and pieces. once the community exists, then JCS could apply for promotion out of the commons. Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). (just to set the record straight on commons-configuration) sandbox components are not allowed to have releases. one major factor when promotion (to the commons proper) is being consider is that a component is ready for a release (even if it's a 0.1 one). i now think that
RE: [POLL] Future Of Turbine-JCS
I'll be available in January to get started. Let me know what is involved in a release. > -Original Message- > From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 10, 2003 2:51 AM > To: Jakarta General List > Subject: Re: [POLL] Future Of Turbine-JCS > > I'd do it, but I'm not personally involved in JCS. IMHO Martin Poeschl > (who is a Turbineer _and_ works with JCS) would be perfect but I know > that he will be on holidays for a longer time (either already is or will > be soon. Martin?). > > Martin did the Turbine 2.2 release and most of the Torque releases in > the past and I did the 2.3 release of Turbine, so this might count as > "release management experience". ;-) > > Regards > Henning > > > On Tue, 2003-12-09 at 13:13, robert burrell donkin wrote: > > in this case, i'd say we'll need sufficient volunteers from the jakarta > > pmc to ensure oversight during this period. it'd probably be good if > > they were turbineers and if at least one had recent experience of > > release management. > > > > anyone willing to step up? > > > > - robert > > > > On 8 Dec 2003, at 15:28, Aaron Smuts wrote: > > > > > Sounds good. Less disruption on the way to a release would be best. > > > > > > Aaron > > > > > >> -----Original Message- > > >> From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] > > >> Sent: Monday, December 08, 2003 3:22 AM > > >> To: Jakarta General List > > >> Subject: Re: [POLL] Future Of Turbine-JCS > > >> > > >> IMHO too complex. If there is already a JCS list (is there? As you > can > > >> see, I'm a Turbine committer but I have zero overlap with JCS. In > fact > > > I > > >> didn't even know that this is a "turbine sub-sub project" for quite > > > some > > >> time ;-) ), let's keep it. We want to build community? Let's _not_ > > > fold > > >> it into the commons list where a completely different culture exists > > >> compared to a "normal" project list. I'm pretty sure that this will > > >> scare JCS users away. > > >> > > >> I'm thinking that "making it a direct Jakarta sub project" starts to > > >> make more and more sense. I'd propose that we move JCS in this > > >> direction, if the JCS developers push for a 1.0 release inside > > >> turbine-jcs and we make the transition into a Jakarta project with > > > this > > >> 1.0 release (which would IMHO a fine reason to do so). > > >> > > >> Regards > > >> Henning > > >> > > >> > > >> On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: > > >>> On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: > > >>> > > >>>> On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: > > >>>> > > >>>>> Given Robert's description of his experience with the Incubator, > > > I'm > > >>>>> for the > > >>>>> Jakarta Commons to gather some community (direct drop rather than > > >>>>> sandbox > > >>>>> route), with the goal of an eventual promotion to a full > > > sub-project. > > >>>> > > >>>> +1 but direct drop only if the move to the commons is accompanied > > > by a > > >>>> release (1.0 or 0.something, I don't care). > > >>> > > >>> the way that i'd like to see a potential drop working is by folding > > > the > > >>> jcs user and development lists into the commons lists first. this > > > would > > >>> allow the rest of the commons to provide oversight. > > >>> > > >>> next, the JCS team should push towards some kind of release for the > > >>> core engine (even if it's a 0.1 version). once this is ready, we'd > > >>> update the commons website and officially add JCS to the commons. > > >>> hopefully this would provide enough momentum to bootstrap a > > > community > > >>> and to create releases for all the various JCS bits and pieces. once > > >>> the community exists, then JCS could apply for promotion out of the > > >>> commons. > > >>> > > >>>> Else it would not be fair t
Re: [POLL] Future Of Turbine-JCS
I'd do it, but I'm not personally involved in JCS. IMHO Martin Poeschl (who is a Turbineer _and_ works with JCS) would be perfect but I know that he will be on holidays for a longer time (either already is or will be soon. Martin?). Martin did the Turbine 2.2 release and most of the Torque releases in the past and I did the 2.3 release of Turbine, so this might count as "release management experience". ;-) Regards Henning On Tue, 2003-12-09 at 13:13, robert burrell donkin wrote: > in this case, i'd say we'll need sufficient volunteers from the jakarta > pmc to ensure oversight during this period. it'd probably be good if > they were turbineers and if at least one had recent experience of > release management. > > anyone willing to step up? > > - robert > > On 8 Dec 2003, at 15:28, Aaron Smuts wrote: > > > Sounds good. Less disruption on the way to a release would be best. > > > > Aaron > > > >> -Original Message- > >> From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] > >> Sent: Monday, December 08, 2003 3:22 AM > >> To: Jakarta General List > >> Subject: Re: [POLL] Future Of Turbine-JCS > >> > >> IMHO too complex. If there is already a JCS list (is there? As you can > >> see, I'm a Turbine committer but I have zero overlap with JCS. In fact > > I > >> didn't even know that this is a "turbine sub-sub project" for quite > > some > >> time ;-) ), let's keep it. We want to build community? Let's _not_ > > fold > >> it into the commons list where a completely different culture exists > >> compared to a "normal" project list. I'm pretty sure that this will > >> scare JCS users away. > >> > >> I'm thinking that "making it a direct Jakarta sub project" starts to > >> make more and more sense. I'd propose that we move JCS in this > >> direction, if the JCS developers push for a 1.0 release inside > >> turbine-jcs and we make the transition into a Jakarta project with > > this > >> 1.0 release (which would IMHO a fine reason to do so). > >> > >>Regards > >>Henning > >> > >> > >> On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: > >>> On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: > >>> > >>>> On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: > >>>> > >>>>> Given Robert's description of his experience with the Incubator, > > I'm > >>>>> for the > >>>>> Jakarta Commons to gather some community (direct drop rather than > >>>>> sandbox > >>>>> route), with the goal of an eventual promotion to a full > > sub-project. > >>>> > >>>> +1 but direct drop only if the move to the commons is accompanied > > by a > >>>> release (1.0 or 0.something, I don't care). > >>> > >>> the way that i'd like to see a potential drop working is by folding > > the > >>> jcs user and development lists into the commons lists first. this > > would > >>> allow the rest of the commons to provide oversight. > >>> > >>> next, the JCS team should push towards some kind of release for the > >>> core engine (even if it's a 0.1 version). once this is ready, we'd > >>> update the commons website and officially add JCS to the commons. > >>> hopefully this would provide enough momentum to bootstrap a > > community > >>> and to create releases for all the various JCS bits and pieces. once > >>> the community exists, then JCS could apply for promotion out of the > >>> commons. > >>> > >>>> Else it would not be fair to > >>>> many other sub-projects currently in the sandbox which have been > > kept > >>>> there because there is no release (commons-configuration e.g.). > >>> > >>> (just to set the record straight on commons-configuration) sandbox > >>> components are not allowed to have releases. one major factor when > >>> promotion (to the commons proper) is being consider is that a > > component > >>> is ready for a release (even if it's a 0.1 one). i now think that > > every > >>> component in commons proper needs a proper release of some kind so > > that > >>> other projects have the chance to depend on a released versio
Re: jakarta-future Was: [POLL] Future Of Turbine-JCS
On 8 Dec 2003, at 04:20, Phil Steitz wrote: Then maybe instead of breaking it on code-base, we could break it on concept: jakarta-bugs jakarta-announce jakarta-dev jakarta-pmc jakarta-ideas jakarta-site or something. I'm assuming it'll be too noisy, but it is a logical question to ask based on Costin's ideas of opening things up. I understand that the oversight role of the PMC has to include all of Jakarta and I agree that some form of list aggregation/digesting might need to happen to make this practical. I don't think that combining all of the lists is the right way to do it though. This would certainly be a pain for users and contributors who may be interested in only a small number of projects. One way to attack the problem might be to have PMC members who are committers on the different Jakarta projects share the responsibility of maintaining list digests for periodic (weekly?) review by the full PMC and/or alerting the full PMC of any issues that require immediate attention. I guess the alternative would be for all of us to subscribe to all of the lists and take up speed reading ;-) i'd suggest that all new pmc members try subscribing to a number of jakarta lists that they are not committers for. ideally, subscribe to all dev lists and see just how many posts there are even (if you stay on them all only for a few days). it gives a good sense of perspective. if every new pmc member decided to subscribe to just one or two extra lists, then we'd be along way towards solving our current problems with demonstrating oversight (by spreading the load more evenly, we'll eliminate single points of failure). i'd be interested to see the current coverage (in terms of pmc members subscribed to jakarta dev lists). Apologies if this is old ground. I am new to the PMC. it's probably old ground but i'm not sure that we've come up with any good solutions yet :) questions and ideas will therefore be gratefully received :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-future Was: [POLL] Future Of Turbine-JCS
On 8 Dec 2003, at 21:07, Costin Manolache wrote: Henri Yandell wrote: On Wed, 2 Oct 2002, Costin Manolache wrote: Or even better - since jakarta has a single PMC, it could also have a single list of committers ( most of them in the single PMC ). Each PMC member can vote about any jakarta issue - including releases of each sub-project, etc. If the distinction between pmc and committer is fading, then I don't see why do we have to worry about separate karma. A start could be to have every PMC member have karma in every subproject. +1 to jakarta-wide karma. It'd be interesting to look at all the mail-traffic for Jakarta and estimate just how noisy a single project mail list would be. Then maybe instead of breaking it on code-base, we could break it on concept: jakarta-bugs jakarta-announce jakarta-dev jakarta-pmc jakarta-ideas jakarta-site or something. I'm assuming it'll be too noisy, but it is a logical question to ask based on Costin's ideas of opening things up. I don't see the relation between karma and mailing lists. +1 Jakarta does have 2 "global" lists ( jakarta-general and pmc ), and as many sub-project lists are needed. A subproject can create multiple lists if needed/wanted, like commons. i think that multiple lists divide the community and cause problems with oversight. my experience with jakarta commons is that a single list helps to create a community spirit and multiple lists divide this spirit. the avalon community are now strongly against multiple lists and turbine has moved this way also. i've read posts from people in both community expressing the opinion that multiple lists are unhealthy. Each jakarta committer can be on as many lists as he wants. It would be good to keep track of what lists each PMC member is reading currently, or to do something similar with commons, where people add themself to a list of "active" people when they are involved with a component. This will also answer the question "who is monitoring this". seems reasonable. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
in this case, i'd say we'll need sufficient volunteers from the jakarta pmc to ensure oversight during this period. it'd probably be good if they were turbineers and if at least one had recent experience of release management. anyone willing to step up? - robert On 8 Dec 2003, at 15:28, Aaron Smuts wrote: Sounds good. Less disruption on the way to a release would be best. Aaron -Original Message- From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 3:22 AM To: Jakarta General List Subject: Re: [POLL] Future Of Turbine-JCS IMHO too complex. If there is already a JCS list (is there? As you can see, I'm a Turbine committer but I have zero overlap with JCS. In fact I didn't even know that this is a "turbine sub-sub project" for quite some time ;-) ), let's keep it. We want to build community? Let's _not_ fold it into the commons list where a completely different culture exists compared to a "normal" project list. I'm pretty sure that this will scare JCS users away. I'm thinking that "making it a direct Jakarta sub project" starts to make more and more sense. I'd propose that we move JCS in this direction, if the JCS developers push for a 1.0 release inside turbine-jcs and we make the transition into a Jakarta project with this 1.0 release (which would IMHO a fine reason to do so). Regards Henning On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). the way that i'd like to see a potential drop working is by folding the jcs user and development lists into the commons lists first. this would allow the rest of the commons to provide oversight. next, the JCS team should push towards some kind of release for the core engine (even if it's a 0.1 version). once this is ready, we'd update the commons website and officially add JCS to the commons. hopefully this would provide enough momentum to bootstrap a community and to create releases for all the various JCS bits and pieces. once the community exists, then JCS could apply for promotion out of the commons. Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). (just to set the record straight on commons-configuration) sandbox components are not allowed to have releases. one major factor when promotion (to the commons proper) is being consider is that a component is ready for a release (even if it's a 0.1 one). i now think that every component in commons proper needs a proper release of some kind so that other projects have the chance to depend on a released version. i'm not sure why eric hasn't started to push towards promotion for commons-configuration but it's possible that there's addition work that needs doing before commons-configuration is ready. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire "Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen." -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-future Was: [POLL] Future Of Turbine-JCS
On 8 Dec 2003, at 11:10, Christopher Lenz wrote: Am 08.12.2003 um 09:03 schrieb Stefan Bodewig: Can anybody with a better memory for commons than I have recap why the httpclient traffic list has been split off? Did the httpclient developers want a list of their own or have the developers for the other commons components been overwhelmed by httpclient traffic? I think it was a little of both. HttpClient was and continues to be rather heavy in traffic for a commons component, so some started to complain. The developers were okay with splitting off the mailing list, so it happened. I think this was also due to HttpClient being backed by a community separate from the rest of the Commons (i.e. none of the HttpClient contributors is working on other Commons components, IIRC). IIRC the httpclient committers volunteered after a lot of strong-arming from the rest of the commons. IMHO this was a big mistake. it would have been much better if httpclient had remained on the same list (for as long as it had remained in the commons). In my opinion, HttpClient would deserve promotion out of Commons by now, but that's a different topic altogether :-) +1 (but AFAIK no one's proposed it) (i suspect that httpclient would have been promoted already had we not made the misguided decision to split off a separate mailing list.) i've always thought that apache commons would be a perfect fit for httpclient... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-future Was: [POLL] Future Of Turbine-JCS
Henri Yandell wrote: On Wed, 2 Oct 2002, Costin Manolache wrote: Or even better - since jakarta has a single PMC, it could also have a single list of committers ( most of them in the single PMC ). Each PMC member can vote about any jakarta issue - including releases of each sub-project, etc. If the distinction between pmc and committer is fading, then I don't see why do we have to worry about separate karma. A start could be to have every PMC member have karma in every subproject. +1 to jakarta-wide karma. It'd be interesting to look at all the mail-traffic for Jakarta and estimate just how noisy a single project mail list would be. Then maybe instead of breaking it on code-base, we could break it on concept: jakarta-bugs jakarta-announce jakarta-dev jakarta-pmc jakarta-ideas jakarta-site or something. I'm assuming it'll be too noisy, but it is a logical question to ask based on Costin's ideas of opening things up. I don't see the relation between karma and mailing lists. Jakarta does have 2 "global" lists ( jakarta-general and pmc ), and as many sub-project lists are needed. A subproject can create multiple lists if needed/wanted, like commons. Each jakarta committer can be on as many lists as he wants. It would be good to keep track of what lists each PMC member is reading currently, or to do something similar with commons, where people add themself to a list of "active" people when they are involved with a component. This will also answer the question "who is monitoring this". Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Future Of Turbine-JCS
Sounds good. Less disruption on the way to a release would be best. Aaron > -Original Message- > From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Monday, December 08, 2003 3:22 AM > To: Jakarta General List > Subject: Re: [POLL] Future Of Turbine-JCS > > IMHO too complex. If there is already a JCS list (is there? As you can > see, I'm a Turbine committer but I have zero overlap with JCS. In fact I > didn't even know that this is a "turbine sub-sub project" for quite some > time ;-) ), let's keep it. We want to build community? Let's _not_ fold > it into the commons list where a completely different culture exists > compared to a "normal" project list. I'm pretty sure that this will > scare JCS users away. > > I'm thinking that "making it a direct Jakarta sub project" starts to > make more and more sense. I'd propose that we move JCS in this > direction, if the JCS developers push for a 1.0 release inside > turbine-jcs and we make the transition into a Jakarta project with this > 1.0 release (which would IMHO a fine reason to do so). > > Regards > Henning > > > On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: > > On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: > > > > > On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: > > > > > >> Given Robert's description of his experience with the Incubator, I'm > > >> for the > > >> Jakarta Commons to gather some community (direct drop rather than > > >> sandbox > > >> route), with the goal of an eventual promotion to a full sub-project. > > > > > > +1 but direct drop only if the move to the commons is accompanied by a > > > release (1.0 or 0.something, I don't care). > > > > the way that i'd like to see a potential drop working is by folding the > > jcs user and development lists into the commons lists first. this would > > allow the rest of the commons to provide oversight. > > > > next, the JCS team should push towards some kind of release for the > > core engine (even if it's a 0.1 version). once this is ready, we'd > > update the commons website and officially add JCS to the commons. > > hopefully this would provide enough momentum to bootstrap a community > > and to create releases for all the various JCS bits and pieces. once > > the community exists, then JCS could apply for promotion out of the > > commons. > > > > > Else it would not be fair to > > > many other sub-projects currently in the sandbox which have been kept > > > there because there is no release (commons-configuration e.g.). > > > > (just to set the record straight on commons-configuration) sandbox > > components are not allowed to have releases. one major factor when > > promotion (to the commons proper) is being consider is that a component > > is ready for a release (even if it's a 0.1 one). i now think that every > > component in commons proper needs a proper release of some kind so that > > other projects have the chance to depend on a released version. > > > > i'm not sure why eric hasn't started to push towards promotion for > > commons-configuration but it's possible that there's addition work that > > needs doing before commons-configuration is ready. > > > > - robert > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ > > Java, perl, Solaris, Linux, xSP Consulting, Web Services > freelance consultant -- Jakarta Turbine Development -- hero for hire > > "Außerdem können in Deutschland alle Englisch. [...] so entfällt die > Notwendigkeit [...] Deutsch zu lernen." > -- Johan Micoud auf die Frage warum er kein Deutsch spricht. > (http://www.spiegel.de/spiegel/0,1518,273205,00.html) > > > > - > 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-future Was: [POLL] Future Of Turbine-JCS
Am 08.12.2003 um 09:03 schrieb Stefan Bodewig: Can anybody with a better memory for commons than I have recap why the httpclient traffic list has been split off? Did the httpclient developers want a list of their own or have the developers for the other commons components been overwhelmed by httpclient traffic? I think it was a little of both. HttpClient was and continues to be rather heavy in traffic for a commons component, so some started to complain. The developers were okay with splitting off the mailing list, so it happened. I think this was also due to HttpClient being backed by a community separate from the rest of the Commons (i.e. none of the HttpClient contributors is working on other Commons components, IIRC). In my opinion, HttpClient would deserve promotion out of Commons by now, but that's a different topic altogether :-) Cheers, Chris -- Christopher Lenz /=/ cmlenz at gmx.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
IMHO too complex. If there is already a JCS list (is there? As you can see, I'm a Turbine committer but I have zero overlap with JCS. In fact I didn't even know that this is a "turbine sub-sub project" for quite some time ;-) ), let's keep it. We want to build community? Let's _not_ fold it into the commons list where a completely different culture exists compared to a "normal" project list. I'm pretty sure that this will scare JCS users away. I'm thinking that "making it a direct Jakarta sub project" starts to make more and more sense. I'd propose that we move JCS in this direction, if the JCS developers push for a 1.0 release inside turbine-jcs and we make the transition into a Jakarta project with this 1.0 release (which would IMHO a fine reason to do so). Regards Henning On Sun, 2003-12-07 at 17:16, robert burrell donkin wrote: > On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: > > > On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: > > > >> Given Robert's description of his experience with the Incubator, I'm > >> for the > >> Jakarta Commons to gather some community (direct drop rather than > >> sandbox > >> route), with the goal of an eventual promotion to a full sub-project. > > > > +1 but direct drop only if the move to the commons is accompanied by a > > release (1.0 or 0.something, I don't care). > > the way that i'd like to see a potential drop working is by folding the > jcs user and development lists into the commons lists first. this would > allow the rest of the commons to provide oversight. > > next, the JCS team should push towards some kind of release for the > core engine (even if it's a 0.1 version). once this is ready, we'd > update the commons website and officially add JCS to the commons. > hopefully this would provide enough momentum to bootstrap a community > and to create releases for all the various JCS bits and pieces. once > the community exists, then JCS could apply for promotion out of the > commons. > > > Else it would not be fair to > > many other sub-projects currently in the sandbox which have been kept > > there because there is no release (commons-configuration e.g.). > > (just to set the record straight on commons-configuration) sandbox > components are not allowed to have releases. one major factor when > promotion (to the commons proper) is being consider is that a component > is ready for a release (even if it's a 0.1 one). i now think that every > component in commons proper needs a proper release of some kind so that > other projects have the chance to depend on a released version. > > i'm not sure why eric hasn't started to push towards promotion for > commons-configuration but it's possible that there's addition work that > needs doing before commons-configuration is ready. > > - robert > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire "Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen." -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-future Was: [POLL] Future Of Turbine-JCS
On Sun, 07 Dec 2003, Phil Steitz <[EMAIL PROTECTED]> wrote: > It would be very noisy, indeed. Szre. > Here are some stats from October (from message counts displayed at > http://marc.theaimsgroup.com) > > struts tomcat commons > user 3115 2908 375 > dev 759 1131 2112 I guess you could remove half of struts user if we added a jakarta-friday list 8-) Seriously, combining the user lists is not desirable at all IMHO, as our users probably don't care too much for the projects they don't use. Let's look at the dev lists using nagoya's eyebrowse installation and looking at the number of mails in Nevember 2003: Alexandria 3 BCEL 12 BSF8 Cactus 173 Commons 2061 Commons-HTTP-Client 379 ECS0 Jetspeed 283 JMeter 276 Gump 292 (*) Log4J146 Lucene 164 ORO3 Pluto112 POI 213 Regexp21 Slide724 Struts 431 Taglibs 35 Tapestry 110 Tomcat 982 Turbine 271 Turbine-JCS 10 Velocity 244 I think there are more lists than that. (*) using MARC as Gump is not listed in eyebrowse. OK, the total is 6953, more than three times the traffic of commons-dev. This is unless we'd really split the lists into separate lists for bug reports, commits and ideas (I'm not sure I'd like that idea). Can anybody with a better memory for commons than I have recap why the httpclient traffic list has been split off? Did the httpclient developers want a list of their own or have the developers for the other commons components been overwhelmed by httpclient traffic? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-future Was: [POLL] Future Of Turbine-JCS
Henri Yandell wrote: On Wed, 2 Oct 2002, Costin Manolache wrote: Or even better - since jakarta has a single PMC, it could also have a single list of committers ( most of them in the single PMC ). Each PMC member can vote about any jakarta issue - including releases of each sub-project, etc. If the distinction between pmc and committer is fading, then I don't see why do we have to worry about separate karma. A start could be to have every PMC member have karma in every subproject. +1 to jakarta-wide karma. It'd be interesting to look at all the mail-traffic for Jakarta and estimate just how noisy a single project mail list would be. It would be very noisy, indeed. Here are some stats from October (from message counts displayed at http://marc.theaimsgroup.com) struts tomcat commons user 3115 2908 375 dev 759 1131 2112 Then maybe instead of breaking it on code-base, we could break it on concept: jakarta-bugs jakarta-announce jakarta-dev jakarta-pmc jakarta-ideas jakarta-site or something. I'm assuming it'll be too noisy, but it is a logical question to ask based on Costin's ideas of opening things up. I understand that the oversight role of the PMC has to include all of Jakarta and I agree that some form of list aggregation/digesting might need to happen to make this practical. I don't think that combining all of the lists is the right way to do it though. This would certainly be a pain for users and contributors who may be interested in only a small number of projects. One way to attack the problem might be to have PMC members who are committers on the different Jakarta projects share the responsibility of maintaining list digests for periodic (weekly?) review by the full PMC and/or alerting the full PMC of any issues that require immediate attention. I guess the alternative would be for all of us to subscribe to all of the lists and take up speed reading ;-) Apologies if this is old ground. I am new to the PMC. Phil 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]
jakarta-future Was: [POLL] Future Of Turbine-JCS
On Wed, 2 Oct 2002, Costin Manolache wrote: > Or even better - since jakarta has a single PMC, it could also have a single > list of committers ( most of them in the single PMC ). > > Each PMC member can vote about any jakarta issue - including releases of > each sub-project, etc. If the distinction between pmc and committer is > fading, then I don't see why do we have to worry about separate karma. > > A start could be to have every PMC member have karma in every subproject. +1 to jakarta-wide karma. It'd be interesting to look at all the mail-traffic for Jakarta and estimate just how noisy a single project mail list would be. Then maybe instead of breaking it on code-base, we could break it on concept: jakarta-bugs jakarta-announce jakarta-dev jakarta-pmc jakarta-ideas jakarta-site or something. I'm assuming it'll be too noisy, but it is a logical question to ask based on Costin's ideas of opening things up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
robert burrell donkin wrote: > On 4 Dec 2003, at 22:35, Andrew C. Oliver wrote: > > > >> From a Jakarta PMC perspective, I think that we should cease to support >> Sub-sub-projects with the exception of commons.* > > i think that it depends on what's meant by sub-sub-projects :) > > i'm happy for a single sub-project to create many different products > (by this i mean stuff it releases). so, component repositories like > jakarta-commons are fine by me. (some people describe these products as > sub-sub-projects.) > > but i think that each sub-project should only have one list of > committers (though for reasons of security, if a sub-project has more > than one repository, karma for a repository may be given out only on > request) and one development mailing list. so i'd like to prohibit any > sub-sub-projects like jakarta-turbine-JCS. Or even better - since jakarta has a single PMC, it could also have a single list of committers ( most of them in the single PMC ). Each PMC member can vote about any jakarta issue - including releases of each sub-project, etc. If the distinction between pmc and committer is fading, then I don't see why do we have to worry about separate karma. A start could be to have every PMC member have karma in every subproject. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 4 Dec 2003, at 22:35, Andrew C. Oliver wrote: From a Jakarta PMC perspective, I think that we should cease to support Sub-sub-projects with the exception of commons.* i think that it depends on what's meant by sub-sub-projects :) i'm happy for a single sub-project to create many different products (by this i mean stuff it releases). so, component repositories like jakarta-commons are fine by me. (some people describe these products as sub-sub-projects.) but i think that each sub-project should only have one list of committers (though for reasons of security, if a sub-project has more than one repository, karma for a repository may be given out only on request) and one development mailing list. so i'd like to prohibit any sub-sub-projects like jakarta-turbine-JCS. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Future Of Turbine-JCS
> There is also the problem of external dependencies ( if any ). At least > some > of the people on commons preffer commons as more-or-less standalone tools, > that don't require a lot of 'framework'. I don't know JCS, but if it can > be used as a standalone library - it would be great to get it into > commons. It already is standalone as the JCS package naming indicates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 5 Dec 2003, at 09:10, Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). the way that i'd like to see a potential drop working is by folding the jcs user and development lists into the commons lists first. this would allow the rest of the commons to provide oversight. next, the JCS team should push towards some kind of release for the core engine (even if it's a 0.1 version). once this is ready, we'd update the commons website and officially add JCS to the commons. hopefully this would provide enough momentum to bootstrap a community and to create releases for all the various JCS bits and pieces. once the community exists, then JCS could apply for promotion out of the commons. Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). (just to set the record straight on commons-configuration) sandbox components are not allowed to have releases. one major factor when promotion (to the commons proper) is being consider is that a component is ready for a release (even if it's a 0.1 one). i now think that every component in commons proper needs a proper release of some kind so that other projects have the chance to depend on a released version. i'm not sure why eric hasn't started to push towards promotion for commons-configuration but it's possible that there's addition work that needs doing before commons-configuration is ready. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Henning Schmiedehausen wrote: > On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: > >> Given Robert's description of his experience with the Incubator, I'm for >> the Jakarta Commons to gather some community (direct drop rather than >> sandbox route), with the goal of an eventual promotion to a full >> sub-project. > > +1 but direct drop only if the move to the commons is accompanied by a > release (1.0 or 0.something, I don't care). Else it would not be fair to > many other sub-projects currently in the sandbox which have been kept > there because there is no release (commons-configuration e.g.). There is also the problem of external dependencies ( if any ). At least some of the people on commons preffer commons as more-or-less standalone tools, that don't require a lot of 'framework'. I don't know JCS, but if it can be used as a standalone library - it would be great to get it into commons. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
You're kind of being excessively abrasive especially given that I'm just trying to understand the problem as a responsible PMC member. Given that I'm trying to find out about the subject despite having no ties to Turbine or JCS, I'd expect a little less of an obnoxious response. This post certainly doesn't make me want to volunteer to understand the matter or work towards its resolution. On 12/5/03 1:06 AM, "Henning Schmiedehausen" <[EMAIL PROTECTED]> wrote: > On Thu, 2003-12-04 at 23:35, Andrew C. Oliver wrote: >> So far it sounds to me like JCS is only used by Turbine and that only the >> Turbiners really care about it. Thus I don't see why it doesn't just get >> flattened into Turbine and just consider it "one more turbine service". > > +--+ > | Don't | > | feed the | > | Troll! | > +--+ >|| >|| >|| > / \__ > > Come on Andrew, even you can do better than that! > > Obviously you haven't read s single article in this thread, did you?. > JCS is neither a "Turbine Service", nor is it used by Turbine at all. > The fact that it has been developed under the "Turbine label", well it > just happened. But JCS neither depends on Turbine nor the other way > round. So IMHO it is time to move this (IMHO quite decent) project to a > place where it gets much more attention. > > Regards > Henning -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 12/5/03 2:45 AM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote: > Andrew C. Oliver wrote: > >> So far it sounds to me like JCS is only used by Turbine and that only the >> Turbiners really care about it. >> > it is indirectly used by turbine ... that's why the discussion started ... > it is used by torque, ojb, hibernate, > ok, they are all db related .. but i still do not think jcs is db related .. > I think Hibernate is switching to Jgroups anyhow. >> Thus I don't see why it doesn't just get >> flattened into Turbine and just consider it "one more turbine service". >> >> > please go to the jcs site and RTFM > Been there. That¹s why I asked the question. > > As far as oversight, who on the PMC is on this sub-sub-subproject? > > i am > So where do you want it to land? Where do you feel it should go in the mean time. > we should only support sub-sub project if there is a strong relation to > the sub-project ... e.g turbine-fulcrum (avalon components for turbine) > However, I regard that as more than likely just a component of Turbine. More than likely the community is more or less the same. >> -Andy >> >> * before it is mentioned, on POI we call POIFS and HSSF subprojects but >> they're really just components. They're called subprojects by tradition, >> granted it is ambiguous but I'll leave language pedantry to RMS. ;-) >> >> > what is the definition of a sub-sub project?? > Community/technical division. The difference between POI and HTTPD only at a lower level. There aren't any shared committers between POI and HTTPD. POI isn't required for HTTPD and HTTPD isn't required for POI and if POI were housed as part of HTTPD or HTTPD part of POI it wouldn't make a great deal of sense. This is an exaggeration of course but you get the idea. -Andy > martin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
With regard to who is using JCS (or should!). We use it at http://www.officedepot.com Without it I doubt we would be ranked where we are on http://www.ecommercetimes.com/ectpi/ We added a new persisting backend based on an all Java version of gdbm. I found that in a very old version of w3c's Jigsaw server. We also enhanced the p2p caching based on the hashing algorithm used by Squid. Yes we were going to contribute but at the time the JCS folks were trying to extricate JCS into a standalone CVS code base. Things were in flux to say the least. I have a hard time imagining a substantive website without a JSC component. Forward caching of data is just too critical for site speed and scalability. Quoting from Jakarta "The goal of the Apache Jakarta Project is to provide commercial-quality server solutions, based on the Java Platform, developed in an open and cooperative fashion". >From our perspective JCS is on par with Lucene or Log4j, and even Struts as an invaluable server solution component and deserves equal treatment. Regards, Ray Racine On Fri, 2003-12-05 at 08:08, Brian McCallister wrote: > OJB supports using JCS for distributed caching, but I don't know how > many people actually use it (we don't). There is overlap between OJB > and Turbine contributors > > Arrowhead ASP, a GPL ASP interpreter, ( http://www.tripi.com/arrowhead/ > ) also uses JCS as I know the guy who wrote it =) OTOH I don't think he > has ever submitted a patch or even feedback back to the Turbineers. > > I would prefer to see it split off to its own [sub]project if it has > the community around it, but I cannot commit to contributing to it. > > -Brian > > On Dec 4, 2003, at 5:35 PM, Andrew C. Oliver wrote: > > > So far it sounds to me like JCS is only used by Turbine and that only > > the > > Turbiners really care about it. Thus I don't see why it doesn't just > > get elided - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
OJB supports using JCS for distributed caching, but I don't know how many people actually use it (we don't). There is overlap between OJB and Turbine contributors Arrowhead ASP, a GPL ASP interpreter, ( http://www.tripi.com/arrowhead/ ) also uses JCS as I know the guy who wrote it =) OTOH I don't think he has ever submitted a patch or even feedback back to the Turbineers. I would prefer to see it split off to its own [sub]project if it has the community around it, but I cannot commit to contributing to it. -Brian On Dec 4, 2003, at 5:35 PM, Andrew C. Oliver wrote: So far it sounds to me like JCS is only used by Turbine and that only the Turbiners really care about it. Thus I don't see why it doesn't just get flattened into Turbine and just consider it "one more turbine service". However, if it DOES have a community or at the very least someone who loves cares and feeds it, then commons sounds like a reasonable place to build a community. As far as oversight, who on the PMC is on this sub-sub-subproject? From a Jakarta PMC perspective, I think that we should cease to support Sub-sub-projects with the exception of commons.* -Andy * before it is mentioned, on POI we call POIFS and HSSF subprojects but they're really just components. They're called subprojects by tradition, granted it is ambiguous but I'll leave language pedantry to RMS. ;-) On 12/4/03 12:59 PM, "Henri Yandell" <[EMAIL PROTECTED]> wrote: So your preference, as the development-community of JCS, is for a top-level-jakarta project, ie) at the log4j level? If so, we can take that up with the PMC and see what views there are. As the development community, your (and James) views count a lot, though the smallness of community is the worrying thing. Hen On Thu, 4 Dec 2003, Aaron Smuts wrote: The core of JCS is ready for a release. The project is basically a hub for 4 types of plugins, or what are called auxiliaries in JCS: memory, disk, lateral distribution, and remote sever. It requires that you use a memory plugin, but the others are optional. For each type of plugin there is an efficient implementation that people are using. These include: LRU memory manager, indexed disk cache, TCp lateral distribution, and RMI remote server. There are experimental versions of each type of plugin in an experimental source directory: a b-tree disk cache, a database disk cache, a javagroups lateral, a MRU memory manager, and others. The core of JCS is then the hub and these 4 non-experimental plugins. Currently there is only one small bug in the lateral cache recovery process, that I will fix very soon. There are additional features that are mostly extensions of the plugins. I wanted to clean up the group handling features, but this is not crucial. I wanted to add run time defragmentation to the indexed disk cache. I also want to implement clustering on the remote server. Basically, this will involve hooking up remote servers via the TCP lateral cache. All that has to be done is to work out a way to prevent circular calls for there to be clustering. The client can already fail over. I'm not sure what all the levels are called, but if we put JCS at the level of log4j, I guess as a jakarta subproject, and then issue a release, we can find out what else people might want and some more people may be interested in contributing. JCS does not need an overhaul or any significant amount of work on the core features. Most conceivable future development will involve tuning, bug fixes, improving configuration, creating sample applications, and extension development. Aaron - 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] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - 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: [POLL] Future Of Turbine-JCS
Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). Yes, I like that stipulation. A 1.0 release would do JCS right. - Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Andrew C. Oliver wrote: So far it sounds to me like JCS is only used by Turbine and that only the Turbiners really care about it. it is indirectly used by turbine ... that's why the discussion started ... it is used by torque, ojb, hibernate, ok, they are all db related .. but i still do not think jcs is db related .. Thus I don't see why it doesn't just get flattened into Turbine and just consider it "one more turbine service". please go to the jcs site and RTFM However, if it DOES have a community or at the very least someone who loves cares and feeds it, then commons sounds like a reasonable place to build a community. As far as oversight, who on the PMC is on this sub-sub-subproject? i am From a Jakarta PMC perspective, I think that we should cease to support Sub-sub-projects with the exception of commons.* we should only support sub-sub project if there is a strong relation to the sub-project ... e.g turbine-fulcrum (avalon components for turbine) -Andy * before it is mentioned, on POI we call POIFS and HSSF subprojects but they're really just components. They're called subprojects by tradition, granted it is ambiguous but I'll leave language pedantry to RMS. ;-) what is the definition of a sub-sub project?? martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Thu, 2003-12-04 at 20:43, Daniel Rall wrote: > Given Robert's description of his experience with the Incubator, I'm for the > Jakarta Commons to gather some community (direct drop rather than sandbox > route), with the goal of an eventual promotion to a full sub-project. +1 but direct drop only if the move to the commons is accompanied by a release (1.0 or 0.something, I don't care). Else it would not be fair to many other sub-projects currently in the sandbox which have been kept there because there is no release (commons-configuration e.g.). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Thu, 2003-12-04 at 23:35, Andrew C. Oliver wrote: > So far it sounds to me like JCS is only used by Turbine and that only the > Turbiners really care about it. Thus I don't see why it doesn't just get > flattened into Turbine and just consider it "one more turbine service". +--+ | Don't | | feed the | | Troll! | +--+ || || || / \__ Come on Andrew, even you can do better than that! Obviously you haven't read s single article in this thread, did you?. JCS is neither a "Turbine Service", nor is it used by Turbine at all. The fact that it has been developed under the "Turbine label", well it just happened. But JCS neither depends on Turbine nor the other way round. So IMHO it is time to move this (IMHO quite decent) project to a place where it gets much more attention. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
So far it sounds to me like JCS is only used by Turbine and that only the Turbiners really care about it. Thus I don't see why it doesn't just get flattened into Turbine and just consider it "one more turbine service". However, if it DOES have a community or at the very least someone who loves cares and feeds it, then commons sounds like a reasonable place to build a community. As far as oversight, who on the PMC is on this sub-sub-subproject? >From a Jakarta PMC perspective, I think that we should cease to support Sub-sub-projects with the exception of commons.* -Andy * before it is mentioned, on POI we call POIFS and HSSF subprojects but they're really just components. They're called subprojects by tradition, granted it is ambiguous but I'll leave language pedantry to RMS. ;-) On 12/4/03 12:59 PM, "Henri Yandell" <[EMAIL PROTECTED]> wrote: > > So your preference, as the development-community of JCS, is for a > top-level-jakarta project, ie) at the log4j level? > > If so, we can take that up with the PMC and see what views there are. As > the development community, your (and James) views count a lot, though the > smallness of community is the worrying thing. > > Hen > > On Thu, 4 Dec 2003, Aaron Smuts wrote: > >> The core of JCS is ready for a release. >> >> The project is basically a hub for 4 types of plugins, or what are >> called auxiliaries in JCS: memory, disk, lateral distribution, and >> remote sever. It requires that you use a memory plugin, but the others >> are optional. >> >> For each type of plugin there is an efficient implementation that people >> are using. These include: LRU memory manager, indexed disk cache, TCp >> lateral distribution, and RMI remote server. >> >> There are experimental versions of each type of plugin in an >> experimental source directory: a b-tree disk cache, a database disk >> cache, a javagroups lateral, a MRU memory manager, and others. >> >> The core of JCS is then the hub and these 4 non-experimental plugins. >> Currently there is only one small bug in the lateral cache recovery >> process, that I will fix very soon. >> >> There are additional features that are mostly extensions of the plugins. >> I wanted to clean up the group handling features, but this is not >> crucial. I wanted to add run time defragmentation to the indexed disk >> cache. I also want to implement clustering on the remote server. >> Basically, this will involve hooking up remote servers via the TCP >> lateral cache. All that has to be done is to work out a way to prevent >> circular calls for there to be clustering. The client can already fail >> over. >> >> I'm not sure what all the levels are called, but if we put JCS at the >> level of log4j, I guess as a jakarta subproject, and then issue a >> release, we can find out what else people might want and some more >> people may be interested in contributing. >> >> JCS does not need an overhaul or any significant amount of work on the >> core features. Most conceivable future development will involve tuning, >> bug fixes, improving configuration, creating sample applications, and >> extension development. >> >> Aaron >> >> >> - >> 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] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
The lack of vibrant community is what points to Jakarta Commons as the more appropriate place, a place where a community could grow for JCS. I'd rather see JCS as a full sub-project, but without a community to support the software, it would be misplaced as such. Henri Yandell wrote: So your preference, as the development-community of JCS, is for a top-level-jakarta project, ie) at the log4j level? If so, we can take that up with the PMC and see what views there are. As the development community, your (and James) views count a lot, though the smallness of community is the worrying thing. Hen On Thu, 4 Dec 2003, Aaron Smuts wrote: The core of JCS is ready for a release. The project is basically a hub for 4 types of plugins, or what are called auxiliaries in JCS: memory, disk, lateral distribution, and remote sever. It requires that you use a memory plugin, but the others are optional. For each type of plugin there is an efficient implementation that people are using. These include: LRU memory manager, indexed disk cache, TCp lateral distribution, and RMI remote server. There are experimental versions of each type of plugin in an experimental source directory: a b-tree disk cache, a database disk cache, a javagroups lateral, a MRU memory manager, and others. The core of JCS is then the hub and these 4 non-experimental plugins. Currently there is only one small bug in the lateral cache recovery process, that I will fix very soon. There are additional features that are mostly extensions of the plugins. I wanted to clean up the group handling features, but this is not crucial. I wanted to add run time defragmentation to the indexed disk cache. I also want to implement clustering on the remote server. Basically, this will involve hooking up remote servers via the TCP lateral cache. All that has to be done is to work out a way to prevent circular calls for there to be clustering. The client can already fail over. I'm not sure what all the levels are called, but if we put JCS at the level of log4j, I guess as a jakarta subproject, and then issue a release, we can find out what else people might want and some more people may be interested in contributing. JCS does not need an overhaul or any significant amount of work on the core features. Most conceivable future development will involve tuning, bug fixes, improving configuration, creating sample applications, and extension development. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Future Of Turbine-JCS
So your preference, as the development-community of JCS, is for a top-level-jakarta project, ie) at the log4j level? If so, we can take that up with the PMC and see what views there are. As the development community, your (and James) views count a lot, though the smallness of community is the worrying thing. Hen On Thu, 4 Dec 2003, Aaron Smuts wrote: > The core of JCS is ready for a release. > > The project is basically a hub for 4 types of plugins, or what are > called auxiliaries in JCS: memory, disk, lateral distribution, and > remote sever. It requires that you use a memory plugin, but the others > are optional. > > For each type of plugin there is an efficient implementation that people > are using. These include: LRU memory manager, indexed disk cache, TCp > lateral distribution, and RMI remote server. > > There are experimental versions of each type of plugin in an > experimental source directory: a b-tree disk cache, a database disk > cache, a javagroups lateral, a MRU memory manager, and others. > > The core of JCS is then the hub and these 4 non-experimental plugins. > Currently there is only one small bug in the lateral cache recovery > process, that I will fix very soon. > > There are additional features that are mostly extensions of the plugins. > I wanted to clean up the group handling features, but this is not > crucial. I wanted to add run time defragmentation to the indexed disk > cache. I also want to implement clustering on the remote server. > Basically, this will involve hooking up remote servers via the TCP > lateral cache. All that has to be done is to work out a way to prevent > circular calls for there to be clustering. The client can already fail > over. > > I'm not sure what all the levels are called, but if we put JCS at the > level of log4j, I guess as a jakarta subproject, and then issue a > release, we can find out what else people might want and some more > people may be interested in contributing. > > JCS does not need an overhaul or any significant amount of work on the > core features. Most conceivable future development will involve tuning, > bug fixes, improving configuration, creating sample applications, and > extension development. > > Aaron > > > - > 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: [POLL] Future Of Turbine-JCS
The core of JCS is ready for a release. The project is basically a hub for 4 types of plugins, or what are called auxiliaries in JCS: memory, disk, lateral distribution, and remote sever. It requires that you use a memory plugin, but the others are optional. For each type of plugin there is an efficient implementation that people are using. These include: LRU memory manager, indexed disk cache, TCp lateral distribution, and RMI remote server. There are experimental versions of each type of plugin in an experimental source directory: a b-tree disk cache, a database disk cache, a javagroups lateral, a MRU memory manager, and others. The core of JCS is then the hub and these 4 non-experimental plugins. Currently there is only one small bug in the lateral cache recovery process, that I will fix very soon. There are additional features that are mostly extensions of the plugins. I wanted to clean up the group handling features, but this is not crucial. I wanted to add run time defragmentation to the indexed disk cache. I also want to implement clustering on the remote server. Basically, this will involve hooking up remote servers via the TCP lateral cache. All that has to be done is to work out a way to prevent circular calls for there to be clustering. The client can already fail over. I'm not sure what all the levels are called, but if we put JCS at the level of log4j, I guess as a jakarta subproject, and then issue a release, we can find out what else people might want and some more people may be interested in contributing. JCS does not need an overhaul or any significant amount of work on the core features. Most conceivable future development will involve tuning, bug fixes, improving configuration, creating sample applications, and extension development. Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Daniel Rall wrote: Henri Yandell wrote: On Thu, 4 Dec 2003, robert burrell donkin wrote: (i'm a little inclined towards db but) i'd support a proposal from the JCS team for a future in either db or jakarta (along the lines outlined above). guys - have you come to any opinions about what's the best option yet? My only worry with a Commons other than JC is that there's a lot less chance of community. AC and DC need communities to move to them, whereas JCS needs community and JC is the best place to get such a thing. Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. - Dan +1 martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 4 Dec 2003, at 08:17, Daniel Rall wrote: Martin Cooper wrote: On Mon, 1 Dec 2003, Henning Schmiedehausen wrote: [I like "Turbineers". :-) ] > I am one of them, and I did some discussion about JCS @ ApacheCon with Martin Poeschl (who seems to do the odd fix to JCS because he uses it in Torque), another Turbineer. We basically were came to the same conclusion as robert: - JCS is cute and should have a larger exposure - JCS isn't related at all to Turbine. At most it is related to Torque - JCS could be moved to db.apache.org but it is not really database specific - There is (almost) no resistance to move this project out of Turbine. So my vote is It might be a bit early for a vote, everyone not having the same amount of information and all. But seeing as how you prefixed the email POLL, I'm not complaining. ;) i suppose i better explain what i mean by a POLL :) it's a vote but not a VOTE ;) any final binding VOTE will have to happen on the pmc list (for legal reasons) and needs rules and so on. but a vote is very useful way of concentrating a discussion and building a consensus. since a POLL is informal and unofficial, we don't need to waste time making up rules :) so, i thought it's time to revive the [POLL]. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Henri Yandell wrote: On Thu, 4 Dec 2003, robert burrell donkin wrote: (i'm a little inclined towards db but) i'd support a proposal from the JCS team for a future in either db or jakarta (along the lines outlined above). guys - have you come to any opinions about what's the best option yet? My only worry with a Commons other than JC is that there's a lot less chance of community. AC and DC need communities to move to them, whereas JCS needs community and JC is the best place to get such a thing. Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. - Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 4 Dec 2003, at 19:28, Henri Yandell wrote: On Thu, 4 Dec 2003, robert burrell donkin wrote: (i'm a little inclined towards db but) i'd support a proposal from the JCS team for a future in either db or jakarta (along the lines outlined above). guys - have you come to any opinions about what's the best option yet? My only worry with a Commons other than JC is that there's a lot less chance of community. AC and DC need communities to move to them, whereas JCS needs community and JC is the best place to get such a thing. i would say that the right place for JCS at db would be as a direct sub-project (rather than in db commons). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Thu, 4 Dec 2003, robert burrell donkin wrote: > (i'm a little inclined towards db but) i'd support a proposal from the > JCS team for a future in either db or jakarta (along the lines outlined > above). guys - have you come to any opinions about what's the best > option yet? My only worry with a Commons other than JC is that there's a lot less chance of community. AC and DC need communities to move to them, whereas JCS needs community and JC is the best place to get such a thing. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
IMHO the incubator is having some political difficulties at the moment and (from my experience of projects being incubated) it doesn't really help with gathering more developers. having read the thread so far, here's my feelings: 1. i feel strongly that JCS should not continue as a turbine sub-project. 2. i think that JCS could reasonably aspire to be a sub-project of either db or jakarta. 3. i think that the route for JCS to become a jakarta sub-project should be through the commons (in order to develop the strength required for a separate sub-project). (i'm a little inclined towards db but) i'd support a proposal from the JCS team for a future in either db or jakarta (along the lines outlined above). guys - have you come to any opinions about what's the best option yet? - robert On 4 Dec 2003, at 17:45, Henning Schmiedehausen wrote: On Thu, 2003-12-04 at 09:17, Daniel Rall wrote: Jakarta Commons or the Incubator have been my preference for some time now. The Incubator seems like a more appropriate place, as JCS could use some life I was thinking about the incubator, too. But as projects failing to leave the incubator might drop off-ASF completely, we would put JCS (which is already ASF code) to the risk of being dropped out of ASF. That's why I suggested jakarta-commons. (First rule of software acquisition: Once you have the code, never give it back. ;-) ) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire "Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!" -- AOL CD when played backwards (User Friendly - 200-10-15) - 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: [POLL] Future Of Turbine-JCS
On Thu, 2003-12-04 at 09:17, Daniel Rall wrote: > Jakarta Commons or the Incubator have been my preference for some time now. The > Incubator seems like a more appropriate place, as JCS could use some life I was thinking about the incubator, too. But as projects failing to leave the incubator might drop off-ASF completely, we would put JCS (which is already ASF code) to the risk of being dropped out of ASF. That's why I suggested jakarta-commons. (First rule of software acquisition: Once you have the code, never give it back. ;-) ) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire "Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!" -- AOL CD when played backwards (User Friendly - 200-10-15) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Martin Cooper wrote: On Mon, 1 Dec 2003, Henning Schmiedehausen wrote: [I like "Turbineers". :-) ] > I am one of them, and I did some discussion about JCS @ ApacheCon with Martin Poeschl (who seems to do the odd fix to JCS because he uses it in Torque), another Turbineer. We basically were came to the same conclusion as robert: - JCS is cute and should have a larger exposure - JCS isn't related at all to Turbine. At most it is related to Torque - JCS could be moved to db.apache.org but it is not really database specific - There is (almost) no resistance to move this project out of Turbine. So my vote is It might be a bit early for a vote, everyone not having the same amount of information and all. But seeing as how you prefixed the email POLL, I'm not complaining. ;) -->8 (comments here, please) -->8 [ ] leave it within turbine [ ] move it to apache commons [X] move it to jakarta commons [ ] move it to incubator [ ] something else (please specify)... Jakarta Commons or the Incubator have been my preference for some time now. The Incubator seems like a more appropriate place, as JCS could use some life breathed into it, but it is in use so shouldn't somehow end up in the "retired" bin without giving existing projects warning and opportunity to migrate away. Of course, JCS might actually be close to "done", too (though it does still exhibit its share of bugs). If JCS really catches on, we can still move it back to Jakarta as "Jakarta JCS". Yes. This all makes sense to me, and coming from a Turbineer, it's something I would support. It might even provide a path to resolution for what we do with Commons Cache, which is currently in a coma (at best)... Neither Torque and OJB are strictly database projects, and they yet are the poster children of db.apache.org. Is db.apache.org more of a "persistance, caching, and storage meta data" TLP than a straight database project? If so, that's another place that either JCS or Commons Cache could find a more appropriate home. - Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
[ ] leave it within turbine [ ] move it to apache commons [ ] move it to jakarta commons [ ] move it to incubator [ ] something else (please specify)... [1] move it to jakarta [2] move it to db from my point of view jcs should be a jakarta (or db) subproject. martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
[ ] leave it within turbine [3] move it to apache commons [2] move it to jakarta commons [ ] move it to incubator [1] something else (please specify)... I think the ideal place for JCS is the DB Top Level Project. Second choice, Jakarta Commons, and my final choice is Apache Commons. A lot of people are being introduced to JCS through Hibernate, it could use a release, as it does seem to be a great piece of software. I believe that the DB TLP needs more attention, and moving JCS (which IMO should have a much higher profile) to DB would help send some energy towards that project. J-C is my second choice only because, again, I think that JCS (like HiveMind and Jelly) is something that transcends the charter of Jakarta Commons. I would not object to JCS in Jakarta Commons, but I'd rather see us not throw another project into the Jakarta Commons. My last recommendation is the Apache Commons. I hate to feed trolls, but the last round of "discussions" we had about Apache Commons descended into an unproductive rant festival. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 1 Dec 2003, at 12:51, Henning Schmiedehausen wrote: [I like "Turbineers". :-) ] or turbinauts as in 'jason and the turbinauts' ;) If JCS really catches on, we can still move it back to Jakarta as "Jakarta JCS". if JCS really catches on, they might demand a top level ASF project. who knows! - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 1 Dec 2003, at 05:11, Scott Eade wrote: Without knowing too much, should perhaps "JCS to db top level" and "JCS to db commons" also be considered options? definitely :) Of the available options below I have selected jakarta commons more by excluding the other options than because of some perceived positive fit in jakarta commons (though commons is a good place to be no doubt). no need to pick one of the options listed. it's not a VOTE (the reason i listed options was to give a focus). if there are any better options out there, let's consider them. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Mon, 1 Dec 2003, Henning Schmiedehausen wrote: > [I like "Turbineers". :-) ] > > I am one of them, and I did some discussion about JCS @ ApacheCon with > Martin Poeschl (who seems to do the odd fix to JCS because he uses it in > Torque), another Turbineer. We basically were came to the same > conclusion as robert: > > - JCS is cute and should have a larger exposure > - JCS isn't related at all to Turbine. At most it is related to Torque > - JCS could be moved to db.apache.org but it is not really database > specific > - There is (almost) no resistance to move this project out of Turbine. > > So my vote is > > > -->8 > > > > (comments here, please) > > > > -->8 > > [ ] leave it within turbine > > [ ] move it to apache commons > > [X] move it to jakarta commons > > [ ] move it to incubator > > [ ] something else (please specify)... > > > > If JCS really catches on, we can still move it back to Jakarta as > "Jakarta JCS". This all makes sense to me, and coming from a Turbineer, it's something I would support. It might even provide a path to resolution for what we do with Commons Cache, which is currently in a coma (at best)... -- Martin Cooper > > Regards > Henning > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
[I like "Turbineers". :-) ] I am one of them, and I did some discussion about JCS @ ApacheCon with Martin Poeschl (who seems to do the odd fix to JCS because he uses it in Torque), another Turbineer. We basically were came to the same conclusion as robert: - JCS is cute and should have a larger exposure - JCS isn't related at all to Turbine. At most it is related to Torque - JCS could be moved to db.apache.org but it is not really database specific - There is (almost) no resistance to move this project out of Turbine. So my vote is > -->8 > > (comments here, please) > > -->8 > [ ] leave it within turbine > [ ] move it to apache commons > [X] move it to jakarta commons > [ ] move it to incubator > [ ] something else (please specify)... > If JCS really catches on, we can still move it back to Jakarta as "Jakarta JCS". Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire "Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen." -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
- Original Message - From: "Andrew C. Oliver" <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL PROTECTED]> Sent: Sunday, November 30, 2003 7:35 PM Subject: Re: [POLL] Future Of Turbine-JCS > On 11/30/03 6:57 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > > > Geir Magnusson Jr wrote: > > > >> What do the turbine people want? > > > > If we presume the existance of 'turbine people', then that would be a > > good indication that the right thing to do would be to leave JCS within > > turbine, and encourage turbine to be promoted to a top level project, > > taking JCS with it. > > > > If there are not Turbine people then Turbine should be archived and noted as > deprecated. > Please don't feed the trolls :-) > -andy > > > >> On Nov 30, 2003, at 6:08 PM, robert burrell donkin wrote: > >> > >>> On 30 Nov 2003, at 20:41, robert burrell donkin wrote: > >>> > >>> sorry, missed one and probably > >>> > >>> [ ] leave JCS within turbine > >>> [ ] JCS to apache commons > >>> [ ] JCS to jakarta commons > >>> [ ] JCS to jakarta top level > >>> [ ] JCS to incubator > >>> [ ] something else (please specify)... > >>> > >>> ps > >>> > >>> before i get flamed (once again), i'd better add that i think that > >>> it'd be useful to try to get some consensus about where the right > >>> place for JCS is and that's why i started this thread. whatever action > >>> to be taken (if any) will have to be decided on the pmc list. > >>> > >>> - 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] > > > > -- > Andrew C. Oliver > http://www.superlinksoftware.com/poi.jsp > Custom enhancements and Commercial Implementation for Jakarta POI > > http://jakarta.apache.org/poi > For Java and Excel, Got POI? > > The views expressed in this email are those of the author and are almost > definitely not shared by the Apache Software Foundation, its board or its > general membership. In fact they probably most definitively disagree with > everything espoused in the above email. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
JCS should definitely be pulled out to Jakarta Commons to make it more known. I actually came across JCS when I was evaluating Hibernate! I think its a pretty decent software and deserves a higher level of presence. Just my 2 cents. [ ] leave it within turbine [ ] move it to apache commons [X] move it to jakarta commons [ ] move it to incubator [ ] something else (please specify)... -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
robert burrell donkin wrote: (we've done some talking on the pmc list and turbineers have discussed this in the past but since it's not really confidential i'm starting this thread to give everyone a chance to participate.) some information about Turbine-JCS: * JCS has no release * other apache products depend on JCS * JCS is not really directly related to turbine concerns: * JCS is a sub-sub-project with it's own mailing list (this kind of structure has proved difficult to properly supervise) * JCS's health * want to find the 'right' place for JCS -->8 Andy: There most definitely are Turbine people (count me in) - but as Robert suggests above, with it's own mailing list many of us are unaware of JCS. The connection between Turbine and JCS is Torque, which was spun out into db.apache.org some time ago. JCS could well receive more attention if it was located somewhere more appropriate - more attention leads to more users and developers. Without knowing too much, should perhaps "JCS to db top level" and "JCS to db commons" also be considered options? Of the available options below I have selected jakarta commons more by excluding the other options than because of some perceived positive fit in jakarta commons (though commons is a good place to be no doubt). -->8 [ ] leave JCS within turbine [ ] JCS to apache commons [x] JCS to jakarta commons [ ] JCS to jakarta top level [ ] JCS to incubator [ ] something else (please specify)... Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On 11/30/03 6:57 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > Geir Magnusson Jr wrote: > >> What do the turbine people want? > > If we presume the existance of 'turbine people', then that would be a > good indication that the right thing to do would be to leave JCS within > turbine, and encourage turbine to be promoted to a top level project, > taking JCS with it. > If there are not Turbine people then Turbine should be archived and noted as deprecated. -andy >> On Nov 30, 2003, at 6:08 PM, robert burrell donkin wrote: >> >>> On 30 Nov 2003, at 20:41, robert burrell donkin wrote: >>> >>> sorry, missed one and probably >>> >>> [ ] leave JCS within turbine >>> [ ] JCS to apache commons >>> [ ] JCS to jakarta commons >>> [ ] JCS to jakarta top level >>> [ ] JCS to incubator >>> [ ] something else (please specify)... >>> >>> ps >>> >>> before i get flamed (once again), i'd better add that i think that >>> it'd be useful to try to get some consensus about where the right >>> place for JCS is and that's why i started this thread. whatever action >>> to be taken (if any) will have to be decided on the pmc list. >>> >>> - 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] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Nov 30, 2003, at 9:57 PM, Sam Ruby wrote: Geir Magnusson Jr wrote: What do the turbine people want? If we presume the existance of 'turbine people', then that would be a good indication that the right thing to do would be to leave JCS within turbine, and encourage turbine to be promoted to a top level project, taking JCS with it. Why? There are "Gump people", "Tomcat people", "struts people", "taglib people", etc. There's nothing wrong with recognizing that the various citizens of Jakarta work on different things. And if Turbine wants to go to TLP, +1 from me. geir On Nov 30, 2003, at 6:08 PM, robert burrell donkin wrote: On 30 Nov 2003, at 20:41, robert burrell donkin wrote: sorry, missed one and probably [ ] leave JCS within turbine [ ] JCS to apache commons [ ] JCS to jakarta commons [ ] JCS to jakarta top level [ ] JCS to incubator [ ] something else (please specify)... ps before i get flamed (once again), i'd better add that i think that it'd be useful to try to get some consensus about where the right place for JCS is and that's why i started this thread. whatever action to be taken (if any) will have to be decided on the pmc list. - 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Geir Magnusson Jr wrote: What do the turbine people want? If we presume the existance of 'turbine people', then that would be a good indication that the right thing to do would be to leave JCS within turbine, and encourage turbine to be promoted to a top level project, taking JCS with it. On Nov 30, 2003, at 6:08 PM, robert burrell donkin wrote: On 30 Nov 2003, at 20:41, robert burrell donkin wrote: sorry, missed one and probably [ ] leave JCS within turbine [ ] JCS to apache commons [ ] JCS to jakarta commons [ ] JCS to jakarta top level [ ] JCS to incubator [ ] something else (please specify)... ps before i get flamed (once again), i'd better add that i think that it'd be useful to try to get some consensus about where the right place for JCS is and that's why i started this thread. whatever action to be taken (if any) will have to be decided on the pmc list. - 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: [POLL] Future Of Turbine-JCS
What do the turbine people want? On Nov 30, 2003, at 6:08 PM, robert burrell donkin wrote: On 30 Nov 2003, at 20:41, robert burrell donkin wrote: sorry, missed one and probably [ ] leave JCS within turbine [ ] JCS to apache commons [ ] JCS to jakarta commons [ ] JCS to jakarta top level [ ] JCS to incubator [ ] something else (please specify)... ps before i get flamed (once again), i'd better add that i think that it'd be useful to try to get some consensus about where the right place for JCS is and that's why i started this thread. whatever action to be taken (if any) will have to be decided on the pmc list. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
On Mon, 1 Dec 2003 07:41 am, robert burrell donkin wrote: > (we've done some talking on the pmc list and turbineers have discussed > this in the past but since it's not really confidential i'm starting > this thread to give everyone a chance to participate.) > Have we asked the JCS developers what they want to do? We may be better off telling them that they should change their organization and let them decide what is the most appropriate move to make. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
At 10:08 AM 1/12/2003, you wrote: [ ] leave JCS within turbine [ ] JCS to apache commons [X] JCS to jakarta commons [ ] JCS to jakarta top level [ ] JCS to incubator [ ] something else (please specify)... Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/
Re: [POLL] Future Of Turbine-JCS
On 30 Nov 2003, at 20:41, robert burrell donkin wrote: sorry, missed one and probably [ ] leave JCS within turbine [ ] JCS to apache commons [ ] JCS to jakarta commons [ ] JCS to jakarta top level [ ] JCS to incubator [ ] something else (please specify)... ps before i get flamed (once again), i'd better add that i think that it'd be useful to try to get some consensus about where the right place for JCS is and that's why i started this thread. whatever action to be taken (if any) will have to be decided on the pmc list. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
People looking for java components at apache look first at jakarta commons. I already referred some people asking for a cache component on the commons-user mailing list. Looking at the number of messages (on the turbine-jcs-* lists) moving to the incubator or somewhere else to become a TLP is too soon IMHO. But JCS has the right size for jakarta commons. > -- > [ ] leave it within turbine > [ ] move it to apache commons > [X] move it to jakarta commons > [ ] move it to incubator > [ ] something else (please specify)... > -- -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] Future Of Turbine-JCS
(we've done some talking on the pmc list and turbineers have discussed this in the past but since it's not really confidential i'm starting this thread to give everyone a chance to participate.) some information about Turbine-JCS: * JCS has no release * other apache products depend on JCS * JCS is not really directly related to turbine concerns: * JCS is a sub-sub-project with it's own mailing list (this kind of structure has proved difficult to properly supervise) * JCS's health * want to find the 'right' place for JCS -->8 (comments here, please) -->8 [ ] leave it within turbine [ ] move it to apache commons [ ] move it to jakarta commons [ ] move it to incubator [ ] something else (please specify)... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
