openstack team mailing list archive

[Lloyd Dewolf <lloydostack@xxxxxxxxx>]

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/