openstack team mailing list archive

[Endre Karlson <endre.karlson@xxxxxxxxx>]

---------- Videresendt melding ----------
Fra: "Endre Karlson" <endre.karlson@xxxxxxxxx>
Dato: 23. juni 2012 12:05
Emne: Re: [Openstack] Thoughts on client library releasing
Til: "Lloyd Dewolf" <lloydostack@xxxxxxxxx>

What about doing like discovery documents like google does?
Den 23. juni 2012 00:27 skrev "Lloyd Dewolf" <lloydostack@xxxxxxxxx>
følgende:

On Fri, Jun 22, 2012 at 6:00 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx>
> wrote:
> > Mark McLoughlin wrote:
> >> That actually goes to something I'm not aware of us - the project -
> >> having spent much time discussing. We do twice yearly releases of our
> >> collection of software, but there are public cloud providers which want
> >> to essentially do continuous deployment from our development branch.
> >>
> >> To what extent is that a reasonable thing for the project to support? If
> >> we had a shorter release cycle, would the cloud providers switch their
> >> deployments from continuous to the releases? If not, can the project and
> >> cloud providers better co-ordinate somehow?
> >
> > That's a discussion we had before the Essex release, when we were
> > looking into releasing more often (every 5-8 weeks) instead of every 6
> > months. "What makes a release ?". After all, you will never prevent
> > people from using milestones or random snapshots, and we should strive
> > to make master always installable and working. So why do releases ? And
> > what should be the cadence ?
> >
> > To me, releases are synchronization points. We have to have a cycle with
> > a timeframe where development slows down at one point to let QA,
> > documentation, integration testing and translation catch-up. A release
> > is a point in time where the stars are all aligned. The release cycle is
> > there to help us achieve that regularly.
> >
> > Those synchronization points also serve to maintain stable branches and
> > coordinate with distros (it's no mystery that we are cadenced in a way
> > that makes us friendly with time-based distros).
> >
> > Currently we can only achieve that star-aligning process every 6 months,
> > but I hope that we'll be able to do releases more often in the future.
> >
> > That said, us releasing every 6 months doesn't mean we should prevent
> > users from being able to pick a version and run with it. In particular,
> > I think our client library release scheme shouldn't actively go against
> > that by synchronizing too much with the core release schedule.
>
> Well said, as have all the contributions to the discussion.
>
> Right now Piston Cloud maintains our own "clients" based on the full
> packages of Diablo with fixes from newer releases -- like being able
> to installing all of glance using pip to get to the client libraries.
>
> I can't wait for the releases of the glance and swift client libraries.
> https://github.com/openstack/python-swiftclient
> https://github.com/openstack/python-glanceclient
>
> If not their own "projects" within launchpad for client library  will
> severe issues and lengthening resolved bug lists have the visibility
> for a natural release management? What tools will support the client
> libraries having good cadence?
>
> On the other hand separation is artificial when it's the same
> technical owners and the client libraries evolve hand-in-hand with the
> servers.
>
> My recommendation -- although being their own Launchpad projects makes
> many of the answers for release management more obvious and far easier
> -- would be to get a baseline of quality client libraries, and leave
> them fully embedded in the servers' projects, versioned the same as
> the servers, until demonstrated that isn't working, and re-evaluation
> on a bug backlog by bug backlog basis.
>
>
> Thank you,
> --
> @lloyddewolf
> http://www.pistoncloud.com/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>