Open Stack

Mark McLoughlin <markmc at redhat.com> writes:

> When the API is ready for a library release, we either create a new
> library that installs into the 'oslo' namespace package or add it to an
> existing library. Either way, it moves out of oslo-incubator at that
> point and switch to using it as a normal library API.
>
> The point of calling the repo oslo-incubator is to reinforce the idea
> that code isn't intended to live their forever. It's a stepping stone
> towards a proper library release.
>
> I think this will all become more obvious to everyone after we do our
> first library release. We're starting with oslo-config once some last
> minute things are wrapped up:
>
>   https://github.com/markmc/oslo-config

Thanks for the clarification.  Your last link suggests some questions
about the details of the process of splitting off a stable library from
incubation.

Are you planning on continuing to host the development of libraries in
the project infrastructure, with the tree in /markmc just a platform for
doing an initial import into Gerrit?

The tree to which you linked contains only one commit with no
development history of the files in it.  I think it would be better to
clone the repo and rewrite the history to remove irrelevant files
leaving the history of the final files intact.  We've done this a few
times when we broke out projects (such as jenkins-job-builder and
gerritlib) from the openstack-ci-puppet project.

Additionally, the openstack-common project still exists in Launchpad.  I
noticed you moved all the bugs to olso, however, new ones have been
reported since then.  I think to avoid confusion, we should delete the
openstack-common project, or at least disable all its features and
change the description to point people at oslo.

And finally, once this is all hashed out, it might be a good idea to
have a wiki page describing the Oslo intent and process.

-Jim