Is the plan is to eventually make CloudMonkey the official CLI for CloudStack (along the lines of the AWS API Tools)? If so, then it would make sense to (eventually) use an Apache repo and synchronize the releases. If not, I don't see any reason to elevate CloudMonkey above any other third party tool that happens to use the CloudStack API.
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 > >
