You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2007/12/14 20:35:44 UTC
GShell 1.0-alpha-1 release update
Folks, the majority of the issues (mostly legal muck) and a few small
bugs/improvements have been cleaned up for the 1.0-alpha-1 release of
GShell.
There is one issue which has been pointed out regarding the 'help'
command, which ATM is less than ideal, but does show the information.
The idea of the 'help' command is to be sort of a combination of 'ls'
and 'man', so that running it with no argument shows the commands
available in the current context, and running with an argument, the
argument is assumed to be a command path, which is resolved and the
help docs for the command are displayed.
To make this work is a little bit more than a minor change, and I've
planned to get it fixed up for the next version (hopefully in a few
months)... and really, this is a moderately complex command which is
well suited for someone wanting to learn more about how GShell works
to tackle (which another reason why I didn't make it all super-uber-
sexy).
BUT... I think we really need to get 1.0-alpha-1 released, so it can
be consumed by G 2.1 (as well as other projects which are starting to
use GShell). And IMO, the 'help' commands ugliness is not a big
enough priority to delay the release.
IMO, GShell is still a work in progress, while quite functional for
many purposes, its still a little rough around the edges and will take
some more love to sift through the issues, flesh out the features and
iron those pesky buggers out. My recommendation is that for G 2.1
that we don't advertise GShell as a _feature_, but just let it be
ASIS, handling the CLI bits for G and average users won't really know
the difference. Advanced folks might want to play with it, which is
fine (good even to get more feedback), but I don't think that G 2.1 is
the release where we want to unleash this on to the world.
I would rather let GShell cook... and then simmer for a while longer,
pull in more feedback (as now more folks are starting to be aware of
the framework and are implementing tools with it *yay*), fix up the
architecture, fill in some major holes, write some *real*
documentation, and then hand it to the masses... perhaps in G 2.2.
Though keep in mind, GShell isn't really Geronimo-specific... its
intended to be a light(ish) framework for building rich command-line
applications. It just so happens that Geronimo needs such a system to
handle its growing cli needs. And GShell's remote login feature makes
it ideal for administrators to use that cli to perform installs,
maintenance, scripts ala BSF or whatever.
Geronimo is definitely, well... IMO, an ideal candidate for GShell
integration and I really believe that there is a *huge* value add
here. But... before we go telling the world how dope the GShell
integration in Geronimo is... I'd really like to fix some of its warts
and create some documentation.
* * *
Anyways, the point of this email is really to ask you folks... can we
live with how GShell works right now for the 1.0-alpha-1 release? Or
are their any blocking issues which *must* be resolved?
I'd really like to spin up a vote today or tomorrow... so if anyone
has any input... now is the time.
--jason
PS. Thanks for those of you who have taken time to play with GShell
and provided feedback. Your input is invaluable and IMO critical to
the growth and success of GShell. So thanks again!
Re: GShell 1.0-alpha-1 release update
Posted by Kevan Miller <ke...@gmail.com>.
Oops. Sorry I was offline yesterday evening playing taxi driver...
On Dec 15, 2007, at 12:23 AM, Jason Dillon wrote:
> No worries take a whack at it. Though IMO its too bad the "apache
> way" slows down releasing binaries so much. Like I want to push out
> alpha-1 um like a week ago. I know there are holes, which well filla
> nd then roll out another alpha.
Not sure in what manner the "apache way" has slowed this down. Getting
licensing info correct? May be a PITA, but don't see how that's a bad
thing... Sorry I got a bit time-constrained. It's not like I really
enjoy it, either -- which doesn't help...
If you were constrained by implementing forward looking function, then
svn cp https://svn.apache.org/repos/asf/geronimo/gshell/trunk https://svn.apache.org/repos/asf/geronimo/gshell/branches/1.0-alpha-1
might have been useful
People may feel that alpha-1 is good enough... Or Gshell may be at
alpha-2 by the time G is ready to release
>
>
> Its certainly not going to be perfect that's for sure. Which is why
> I tend to follow the release often strategy. Push out something that
> is functional, fix it up and then push it out again.
>
> Seems to me like we have a 2-3 week minumum for each release, almost
> regaurdless of what it is... Though the javaee server and its tck
> muck certainly adds on more weeks.
>
> It seems like if nothing at all changed ina subproject it will still
> take the better part of a month to make a release :-(
>
> Well take a look... Let's try to get this finished in the next week
> na... I'm goinig to be out of the country for 3 weeks startin on the
> 22nd.... And I'd reallly, really like to have the release done by
> then....
Heh. Now you tell me... Sorry, you need to cancel... :-P I can use
that as part of my evaluation criteria...
>
>
> But more so I think we need to rethink our stratagy. on
> releases.... It should be easy and quick. IMO the 3 day vote period
> is long enough :-P
>
> Well ping me if you need something changed. I'm at your disposal
> next week if it helps move things along...aight?
I have no issues with release early, release often. However, I will
tend to hold Gshell releases slated for a Geronimo release to a higher
standard than I might otherwise. Once there's a stable gshell release
base, this may become less of an issue...
--kevan
Re: GShell 1.0-alpha-1 release update
Posted by Jason Dillon <ja...@planet57.com>.
No worries take a whack at it. Though IMO its too bad the "apache way" slows down releasing binaries so much. Like I want to push out alpha-1 um like a week ago. I know there are holes, which well filla nd then roll out another alpha.
Its certainly not going to be perfect that's for sure. Which is why I tend to follow the release often strategy. Push out something that is functional, fix it up and then push it out again.
Seems to me like we have a 2-3 week minumum for each release, almost regaurdless of what it is... Though the javaee server and its tck muck certainly adds on more weeks.
It seems like if nothing at all changed ina subproject it will still take the better part of a month to make a release :-(
Well take a look... Let's try to get this finished in the next week na... I'm goinig to be out of the country for 3 weeks startin on the 22nd.... And I'd reallly, really like to have the release done by then....
But more so I think we need to rethink our stratagy. on releases.... It should be easy and quick. IMO the 3 day vote period is long enough :-P
Well ping me if you need something changed. I'm at your disposal next week if it helps move things along...aight?
:-)
--jason
-----Original Message-----
From: Kevan Miller <ke...@gmail.com>
Date: Fri, 14 Dec 2007 20:07:07
To:dev@geronimo.apache.org
Subject: Re: GShell 1.0-alpha-1 release update
On Dec 14, 2007, at 3:12 PM, Jason Dillon wrote:
> I *completely* agree!!
>
> I'm going to give it the rest of the day for feedback on my email
> and if there is no decent, then I will start the vote.
At the moment, some Geronimo commands are/will be(?) available *only*
through gshell (e.g. assemble). So, I'm interested in insuring that
gshell does have "meets-min" capabilities. You could argue that we
should have console/java cli support for these functions (or I'm just
wrong... ;-), but that's the way things are ATM...
I'm not advocating for a more robust 'help' command. However, I would
like to be sure it's readable and instructive.
Personally, I'd like to take a little time to kick the tires and make
sure we don't have any glaring problems...
--kevan
Re: GShell 1.0-alpha-1 release update
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 14, 2007, at 3:12 PM, Jason Dillon wrote:
> I *completely* agree!!
>
> I'm going to give it the rest of the day for feedback on my email
> and if there is no decent, then I will start the vote.
At the moment, some Geronimo commands are/will be(?) available *only*
through gshell (e.g. assemble). So, I'm interested in insuring that
gshell does have "meets-min" capabilities. You could argue that we
should have console/java cli support for these functions (or I'm just
wrong... ;-), but that's the way things are ATM...
I'm not advocating for a more robust 'help' command. However, I would
like to be sure it's readable and instructive.
Personally, I'd like to take a little time to kick the tires and make
sure we don't have any glaring problems...
--kevan
Re: GShell 1.0-alpha-1 release update
Posted by Jason Dillon <ja...@planet57.com>.
I *completely* agree!!
I'm going to give it the rest of the day for feedback on my email and
if there is no decent, then I will start the vote.
--jason
On Dec 14, 2007, at 11:51 AM, Guillaume Nodet wrote:
> I'd like to release GShell asap. Having more frequent release is
> imho a good idea (though it's usually easier to say than to do...).
> GShell is already useful, even if there is still lots of things to do.
>
> On Dec 14, 2007 8:35 PM, Jason Dillon <ja...@planet57.com> wrote:
> Folks, the majority of the issues (mostly legal muck) and a few small
> bugs/improvements have been cleaned up for the 1.0-alpha-1 release of
> GShell.
>
> There is one issue which has been pointed out regarding the 'help'
> command, which ATM is less than ideal, but does show the information.
> The idea of the 'help' command is to be sort of a combination of 'ls'
> and 'man', so that running it with no argument shows the commands
> available in the current context, and running with an argument, the
> argument is assumed to be a command path, which is resolved and the
> help docs for the command are displayed.
>
> To make this work is a little bit more than a minor change, and I've
> planned to get it fixed up for the next version (hopefully in a few
> months)... and really, this is a moderately complex command which is
> well suited for someone wanting to learn more about how GShell works
> to tackle (which another reason why I didn't make it all super-uber-
> sexy).
>
> BUT... I think we really need to get 1.0-alpha-1 released, so it can
> be consumed by G 2.1 (as well as other projects which are starting to
> use GShell). And IMO, the 'help' commands ugliness is not a big
> enough priority to delay the release.
>
> IMO, GShell is still a work in progress, while quite functional for
> many purposes, its still a little rough around the edges and will take
> some more love to sift through the issues, flesh out the features and
> iron those pesky buggers out. My recommendation is that for G 2.1
> that we don't advertise GShell as a _feature_, but just let it be
> ASIS, handling the CLI bits for G and average users won't really know
> the difference. Advanced folks might want to play with it, which is
> fine (good even to get more feedback), but I don't think that G 2.1 is
> the release where we want to unleash this on to the world.
>
> I would rather let GShell cook... and then simmer for a while longer,
> pull in more feedback (as now more folks are starting to be aware of
> the framework and are implementing tools with it *yay*), fix up the
> architecture, fill in some major holes, write some *real*
> documentation, and then hand it to the masses... perhaps in G 2.2.
>
> Though keep in mind, GShell isn't really Geronimo-specific... its
> intended to be a light(ish) framework for building rich command-line
> applications. It just so happens that Geronimo needs such a system to
> handle its growing cli needs. And GShell's remote login feature makes
> it ideal for administrators to use that cli to perform installs,
> maintenance, scripts ala BSF or whatever.
>
> Geronimo is definitely, well... IMO, an ideal candidate for GShell
> integration and I really believe that there is a *huge* value add
> here. But... before we go telling the world how dope the GShell
> integration in Geronimo is... I'd really like to fix some of its warts
> and create some documentation.
>
> * * *
>
> Anyways, the point of this email is really to ask you folks... can we
> live with how GShell works right now for the 1.0-alpha-1 release? Or
> are their any blocking issues which *must* be resolved?
>
> I'd really like to spin up a vote today or tomorrow... so if anyone
> has any input... now is the time.
>
> --jason
>
> PS. Thanks for those of you who have taken time to play with GShell
> and provided feedback. Your input is invaluable and IMO critical to
> the growth and success of GShell. So thanks again!
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
Re: GShell 1.0-alpha-1 release update
Posted by Guillaume Nodet <gn...@gmail.com>.
I'd like to release GShell asap. Having more frequent release is imho a
good idea (though it's usually easier to say than to do...).
GShell is already useful, even if there is still lots of things to do.
On Dec 14, 2007 8:35 PM, Jason Dillon <ja...@planet57.com> wrote:
> Folks, the majority of the issues (mostly legal muck) and a few small
> bugs/improvements have been cleaned up for the 1.0-alpha-1 release of
> GShell.
>
> There is one issue which has been pointed out regarding the 'help'
> command, which ATM is less than ideal, but does show the information.
> The idea of the 'help' command is to be sort of a combination of 'ls'
> and 'man', so that running it with no argument shows the commands
> available in the current context, and running with an argument, the
> argument is assumed to be a command path, which is resolved and the
> help docs for the command are displayed.
>
> To make this work is a little bit more than a minor change, and I've
> planned to get it fixed up for the next version (hopefully in a few
> months)... and really, this is a moderately complex command which is
> well suited for someone wanting to learn more about how GShell works
> to tackle (which another reason why I didn't make it all super-uber-
> sexy).
>
> BUT... I think we really need to get 1.0-alpha-1 released, so it can
> be consumed by G 2.1 (as well as other projects which are starting to
> use GShell). And IMO, the 'help' commands ugliness is not a big
> enough priority to delay the release.
>
> IMO, GShell is still a work in progress, while quite functional for
> many purposes, its still a little rough around the edges and will take
> some more love to sift through the issues, flesh out the features and
> iron those pesky buggers out. My recommendation is that for G 2.1
> that we don't advertise GShell as a _feature_, but just let it be
> ASIS, handling the CLI bits for G and average users won't really know
> the difference. Advanced folks might want to play with it, which is
> fine (good even to get more feedback), but I don't think that G 2.1 is
> the release where we want to unleash this on to the world.
>
> I would rather let GShell cook... and then simmer for a while longer,
> pull in more feedback (as now more folks are starting to be aware of
> the framework and are implementing tools with it *yay*), fix up the
> architecture, fill in some major holes, write some *real*
> documentation, and then hand it to the masses... perhaps in G 2.2.
>
> Though keep in mind, GShell isn't really Geronimo-specific... its
> intended to be a light(ish) framework for building rich command-line
> applications. It just so happens that Geronimo needs such a system to
> handle its growing cli needs. And GShell's remote login feature makes
> it ideal for administrators to use that cli to perform installs,
> maintenance, scripts ala BSF or whatever.
>
> Geronimo is definitely, well... IMO, an ideal candidate for GShell
> integration and I really believe that there is a *huge* value add
> here. But... before we go telling the world how dope the GShell
> integration in Geronimo is... I'd really like to fix some of its warts
> and create some documentation.
>
> * * *
>
> Anyways, the point of this email is really to ask you folks... can we
> live with how GShell works right now for the 1.0-alpha-1 release? Or
> are their any blocking issues which *must* be resolved?
>
> I'd really like to spin up a vote today or tomorrow... so if anyone
> has any input... now is the time.
>
> --jason
>
> PS. Thanks for those of you who have taken time to play with GShell
> and provided feedback. Your input is invaluable and IMO critical to
> the growth and success of GShell. So thanks again!
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/