openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #04834
Re: Packaging changes based on discussions at ODS
Hi all -
I believe the packages are the source of many many complaints about the
documentation for Diablo, so I feel my reputation as a writer is on the line
due to the bad experience people are having with installing (all) the
OpenStack projects right now.
I was in the backporting session last week, and many distros sound like
they'd prefer to package up themselves. However I didn't hear such a strong
conclusion that the CI team would stop packaging completely except for devs.
This seems like a poor choice for supporting the many non-devs in our
community.
If there are packages that work and are being maintained, I will point the
official docs to them, but it seems poor form to point official docs to
seemingly unofficial packages.
My main goal here is to stop the (justified) complaining about the docs not
working. If the best way to do that is to point to specific team's packages,
please let me know.
One additional note that I have to also add. I don't really think it's fair
to have a mostly dev-audience make decisions about something that affects
the installation and getting started process so drastically. Can we please
revisit the discussion and continue it more here?
Thanks,
Anne
*Anne Gentle*
anne@xxxxxxxxxxxxx
my blog <http://justwriteclick.com/> | my
book<http://xmlpress.net/publications/conversation-community/>|
LinkedIn <http://www.linkedin.com/in/annegentle> |
Delicious<http://del.icio.us/annegentle>|
Twitter <http://twitter.com/annegentle>
On Thu, Oct 13, 2011 at 11:04 AM, Monty Taylor <mordred@xxxxxxxxxxxx> wrote:
> Hey all,
>
> There were many exciting and productive conversations around packaging
> and the role of OpenStack as an upstream entity in producing distro
> packages. Turns out, the general consensus was that the project was
> spending a bunch of effort to produce packages that no one was using or
> really interested in using. Additionally, we were making packages in an
> attempt to help make the distros lives easier, but it actually was
> making things more difficult.
>
> As a result, in order to be a good upstream that facilitates the works
> of distros and other packagers, for essex we're going to stop producing
> ubuntu packages as an output of the project. Instead we will rely on the
> distros and integrators/vendors to provide an end-user consumable thing
> and keep our focus on supporting developers. This has several specific
> changes:
>
> - Jenkins jobs are going to start using the venv/pip-based version of
> run_tests.sh.
>
> - We will not be uploading nova/swift/glance/keystone to PPAs.
>
> - We will still maintain a PPA with backport packages of depends for dev
> purposes (things like libvirt) This will be a new PPA though, as there
> is really no point in having separate PPAs for each project any more.
>
> - We will be setting up a PyPI mirror into which we will publish
> pip-able packages for every trunk commit. This will be more useful for
> devs wanting to develop, say, nova against the latest keystone. It will
> not be intended for people to deploy from.
>
> - We're going to base a bunch of jenkins integration testing jobs on the
> devstack work from cloudbuilders, as it does a simple deploy into a
> container and is something that a dev can use locally to reproduce
> problems that they might see reported by jenkins.
>
> It's going to take us a little bit to get this sorted in a way that's
> not disruptive. If we do it right, you should mostly not notice - other
> than the PPA change for folks who are wanting to install depend packages
> - but I'll announce that when it happens... and of course the old ppas
> will still exist but just be deprecated.
>
> I'll follow up with implementation details as they happen.
>
> Thanks!
> Monty
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References