On 06-Jan-2013, at 4:11 PM, Chris Sears <chris.x.se...@sungard.com> wrote:
> Is the plan is to eventually make CloudMonkey the official CLI for > CloudStack (along the lines of the AWS API Tools)? Yes we wanted a command line tool: https://issues.apache.org/jira/browse/CLOUDSTACK-132 This is the reason why I did not create a separate repo for it and also because it's dependent on the maven build target (apidocs/marvin which helps it generate a pre cache of all the apis, their params and docstrings). > If so, then it would > make sense to (eventually) use an Apache repo and synchronize the releases. There is no such thing as an Apache repo, cheese shop or pypi.python.org is a standard place to distribute python programs, libs etc. and uses pip as its pkg manager, which is why it was published on pypi. > If not, I don't see any reason to elevate CloudMonkey above any other third > party tool that happens to use the CloudStack API. No it's not, it's just another client for CloudStack, one can work on their own clients. Regards. > > > On Sun, Jan 6, 2013 at 6:37 PM, David Nalley <da...@gnsa.us> wrote: > >> On Sun, Jan 6, 2013 at 4:39 PM, Rohit Yadav <rohit.ya...@citrix.com> >> wrote: >>> >>> On 06-Jan-2013, at 1:31 PM, Sebastien Goasguen <run...@gmail.com> wrote: >>>> >>>> Can't we just consider cloudmonkey source as "stable" release within a >> cloudstack release. and just consider the pypi as "unstable" dev.. >>>> >>>> after all anyone can grab cloudmonkey latest from master and push it to >> pypi ... >>>> >>>> IMHO it's just an issue of understanding that pypi release is not an >> official ACS release artifact. >>> >>> I think for now let's keep it that way, or we can have frequent release >> cycles of cloudmonkey that are being voted by community and released on >> pypi? >>> >> >> So lots of places do 'unofficial' releases, but what is odd here is: >> >> 1. We (the ACS community) have no plans around releasing Cloudmonkey. >> (unless the plan is to make it a part of the CloudStack release.) >> Anecdotally I hear that Apache communities in the past who have had >> 3rd parties release 'development' snapshots and never release the >> software themselves have had the board take issue with that behavior. >> 2. It has a version number - despite never being released, a version >> number exists. Typically when an individual releases development >> snapshots (as opposed to a community doing a release) it ends up being >> the version number of the last release (or 0 if there has never been a >> release - plus the release tag being incremented to annotate that it's >> either a snapshot or a pre-release package. >> 3. What happens if the ACS community decides that it wants to release >> CloudMonkey version 1.0.0 at some point in the future? IMO defining a >> version number is equivalent to performing a release. >> 4. How (in your current scheme) would you delineate between snapshot >> packaging (what you've done heretofore) and a real release? >> 5. Follow-on question to that. How do you file bugs against it? The >> primary way folks get access to cloudmonkey is to install it from pypi >> I'd suppose. There is no revision information in the releases - there >> are 4 different releases (with the difference being the release tag, >> but presumably those are different pieces of code. How does one even >> know where in time their version is? >> >> In short I see a huge number of potential problems that may manifest >> as we move forward. I am also interested in why you, the primary >> author of CloudMonkey, who sees the need to release more frequently >> hasn't proposed making a separate CloudMonkey release. I don't think >> there is anything inherently that prohibits you from doing so, aside >> from having to handle release management. Yes, a separate repo might >> be cleaner, but I don't know that it means you can't generate a >> release. >> >> Regarding #2 above, take a look at a number of examples of pre-release >> and snapshot packaging here: >> [1] >> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages >> [2] >> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages >> >>
