Open Stack

On Tue, 2012-06-19 at 16:48 +0200, Thierry Carrez wrote:
> Mark McLoughlin wrote:
[..]
> >> However they also inherited the release scheme of the server project
> >> (new version every 6 months), which was (or was not) synced to PyPI
> >> depending of who was owning the PyPI project. More confusion as PyPI
> >> rarely contained the just-released version, since releasing to PyPI was
> >> not handled by OpenStack release management.
> > 
> > I would have thought that only OpenStack release management should be
> > publishing those libs to pypi now.
> 
> PyPI doesn't support complex versioning, nor does it support "channels"
> (think separate repositories for the same library from which you can get
> only daily/milestones/stable-releases).

Nice way of putting it - "channels". I think that helps clarify the
discussion hugely :)

(I guess you could have python-glanceclient-dev as a separate pypi
package to give a similar effect, but that would probably be evil)

[..]

> PyPI only supports one channel. Which one should it be ?

IMHO, PyPI should be a channel where you get:

  - bug fixes

  - support for features which exist in the currently released version
    of OpenStack

  - every six months, support for new features in the just-released 
    version of OpenStack

i.e. we push 2012.1 to pypi when Essex is released and we do 2012.1.x
releases as needed to pypi from our "stable" branch.

Where the definition of "stable" is slightly different - it includes new
features which expose existing REST API features of the associated
release.

i.e. a channel containing (1) and (2) in the split I made.

> > If the issue is integration *within* OpenStack - e.g. Nova needing
> > cinderclient - then I don't think that should dictate the release
> > schedule for these libs. We can surely figure out how to do that without
> > doing more regular official releases of the libs? But first, is that
> > what we're talking about?
> 
> I think so. My understanding is that it's a lot more elegant to rely on
> PyPI for our own libraries, rather than special-casing them for our
> developers and our CI.

For integration in the project, we need the "development channel" and I
don't think we want to pollute pypi with that.

(Again the point about the REST API potentially changing during
development)

So, I don't think I buy this bit and think it's worth digging into the
details.

[..]
> > [...]
> > The way I'm seeing it now is there are three development streams:
> > 
> >   1) bugfixes (i.e. suitable for a stable branch)
> > 
> >   2) new client lib features built on top of existing REST API features 
> >      (e.g. feature additions to the client libs which were released as 
> >      part of Essex which do not require REST API features from Folsom)
> > 
> >   3) new client lib features built on top of new REST API features 
> >      (e.g. the Folsom development stream)
> > 
> > IMHO, if you're J. Random Developer doing 'pip install glanceclient',
> > you probably want (2).
> > 
> > Particularly risk-averse distros may want (1), since (2) is more risky
> > to pull updates from.
> > 
> > And for integration within the project, or folks testing the latest
> > development stream, you want (3).
> > 
> > The project probably can't hope to support all 3 development streams,
> > but can we do (1) and (2) in a "stable" branch and (3) using our usual
> > development release cycle?
> > 
> > Would that satisfy everyone but the "particularly risk-averse distros"?
> 
> That forces us to handle our client library releases outside of PyPI
> though.

It forces us to handle our "development stream" outside of pypi, yes.

Cheers,
Mark.