Re: [Openstack] Packaging changes based on discussions at ODS

2011-10-18 Thread Thierry Carrez
Monty Taylor wrote:
 Totally in terms of the decisions and re-visiting it. I think you're
 totally right, of course, in terms of that.

Your initial email used terms like we are going to, we will or I'll
follow up with implementation details as they happen which certainly
sounds like it's an already-made decision. I'm a bit surprised that you
come up with these conclusions based on last week's discussions, and
that the existing release team (which is ultimately responsible for
those release deliverables) wasn't asked for comments before coming up
with such a strong direction.

 Here's the problem in a nutshell... I can continue to cut packages ...
 but we don't have anybody dedicated to maintaining the contents of the
 packages that we create post-release. (we only just now even got
 branches for maintenance of the branches post-release, and those are
 really mainly a place for the distros to coordinate)

I think you are conflating two problems, and decide to throw out the
baby with the bath water. One issue is the release packages, the other
is the release cycle PPAs.

We don't really want to do post-release maintenance on packages in the
release PPAs, and therefore they are not really usable long-term as a
production install option. One option is definitely to stop producing them.

I just don't see how you jump from that to let's stop producing any
packages. We have been producing packages in PPAs for trunk,
milestone-proposed and last-milestone, and those packages are useful.
They are used daily by testers, developers and integrators. They are by
no means an end product, but they have their own value. Replacing *all
of them* by a single trunk pip repository is just wrong. Where will we
call for testing on milestone-proposed ? Where will integrators be able
to easily get the last milestone ?

Those packages *are* used. PPA stats show more than 33k uses for
nova-core/trunk, 350 uses of milestone-proposed and 480 uses of the
milestone PPA.

In summary, I agree we should now question the release PPAs. I don't see
why we should remove all the other ones in the process. And I disagree
with your presentation of the general consensus and your
already-decided plan.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Packaging changes based on discussions at ODS

2011-10-15 Thread Anne Gentle
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*
a...@openstack.org
 my blog http://justwriteclick.com/ | my
bookhttp://xmlpress.net/publications/conversation-community/|
LinkedIn http://www.linkedin.com/in/annegentle |
Delicioushttp://del.icio.us/annegentle|
Twitter http://twitter.com/annegentle
On Thu, Oct 13, 2011 at 11:04 AM, Monty Taylor mord...@inaugust.com 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@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Packaging changes based on discussions at ODS

2011-10-15 Thread Monty Taylor
Totally in terms of the decisions and re-visiting it. I think you're
totally right, of course, in terms of that.

Here's the problem in a nutshell... I can continue to cut packages ...
but we don't have anybody dedicated to maintaining the contents of the
packages that we create post-release. (we only just now even got
branches for maintenance of the branches post-release, and those are
really mainly a place for the distros to coordinate)

As it winds up now, the way we're releasing packages to the PPA, because
we have to backport upwards of 20 packages, we have a mini linux
distribution. That's fine - and the world knows how to manage linux
distributions - but it creates the implication that we are going to
continue to maintain the release once it's made. Security fixes would be
the big thing ... when a security bug hits diablo, who is going to
manage getting it in to a package release that we as the project are
releasing? What about security bugs in the 20 backported packages?

Now - don't get me wrong. I think it's actually an excellent idea to
publish packages in the way that we have been... in fact, I set up the
original version of it in the first place, and I've been a strong
supporter of it by way of forcing all of the CI builds to use packages
rather than source. So I definitely see the value in having an OpenStack
release targetted at Lucid or at Squeeze. I've been arguing for the
necessity of that for a while ... since it is an area in which the
traditional disto model completely and utterly fails. (mainly because
it's an area in which they are not even trying, since it's kind of
opposite from their model) But to do that takes a will from the project
to support release that we've made - and it was pretty clear in the SRU
talks that the project as it stands now (or at least the devs of the
project) is unwilling and uninterested in supporting such an effort. The
only people who expressed a vocal interest in ongoing maint of diablo
post release _were_ the distros... so since they are the ones bringing
the firepower, we're sort of left with their model of user support.

There's my brain dump. I am ALL EARS for suggestions. And please, just
so that we can keep this discussion focused, I don't actually need any
help in solving the technical challenges of how we cut packages. That's
easy and solved already. The main problem here is the challenge of how
we get appropriate content in to the packages in a post-release world.

Thanks for bringing it up Anne! I really do hope we can find the proper
solution here.

Monty

On 10/15/2011 03:47 PM, Anne Gentle wrote:
 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*
 a...@openstack.org mailto:a...@openstack.org
 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 mord...@inaugust.com
 mailto:mord...@inaugust.com 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