Re: Promoting GShell to a real subproject
Mmkay :-) --jason On Nov 1, 2007, at 7:44 PM, Jeff Genender wrote: Move it ;-) Kevan Miller wrote: No, not in my opinion. I haven't heard of any dissenters. There's been plenty of time for someone to raise an objection. I say -- have at it... --kevan On 11/1/07, *Jason Dillon* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: So shall we move the project out of the sandbox? Do we need an official vote for this? --jason On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Promoting GShell to a real subproject
So shall we move the project out of the sandbox? Do we need an official vote for this? --jason On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Promoting GShell to a real subproject
No, not in my opinion. I haven't heard of any dissenters. There's been plenty of time for someone to raise an objection. I say -- have at it... --kevan On 11/1/07, Jason Dillon [EMAIL PROTECTED] wrote: So shall we move the project out of the sandbox? Do we need an official vote for this? --jason On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Promoting GShell to a real subproject
Thanx Kevan. +1. Cheers Prasad On 10/26/07, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: Promoting GShell to a real subproject
I'm obviously +1 for a sub-project ;-) --jason On Oct 26, 2007, at 10:58 AM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: Promoting GShell to a real subproject
+1 Jason's +1 On Oct 28, 2007, at 6:21 PM, Jason Dillon wrote: I'm obviously +1 for a sub-project ;-) --jason On Oct 26, 2007, at 10:58 AM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: Promoting GShell to a real subproject
Good explanation. +1 to making it a subproject. -Donald Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan smime.p7s Description: S/MIME Cryptographic Signature
Promoting GShell to a real subproject
i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Promoting GShell to a real subproject
I don't see why we shouldn't. But can someone more informed please list the pros and cons. Thanx Prasad On 10/26/07, Guillaume Nodet [EMAIL PROTECTED] wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Promoting GShell to a real subproject
On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: Promoting GShell to a real subproject
On Oct 26, 2007, at 10:58 AM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... Good points. I would also support it as a subproject. Regards, Alan
Re: Promoting GShell to a real subproject
Good explanation Kevan. Seems like it makes sense to be a sub-project. IIUC there isn't a very tight coupling between Geronimo and GShell since the Geronimo specifics are in the command modules. So there is value to be gained in GShell being a subproject. Joe Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: Promoting GShell to a real subproject
+1 Jay Guillaume Nodet [EMAIL PROTECTED] wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Promoting GShell to a real subproject
Makes sense to me. +1 for gshell as a subproject. Best wishes, Paul On Oct 26, 2007, at 1:58 PM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: Promoting GShell to a real subproject
+1 from me. On 10/26/07, Paul McMahan [EMAIL PROTECTED] wrote: Makes sense to me. +1 for gshell as a subproject. Best wishes, Paul On Oct 26, 2007, at 1:58 PM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan -- Davanum Srinivas :: http://davanum.wordpress.com
