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