What a good way to start a long milestone release day. Disclaimer: I used to work for Canonical as the Technical Lead for Ubuntu Server -- and I'm now OpenStack Release Manager.
Like Monty said, this is not the first time the "integrated distribution" model conflicts with deployers needs. This has been discussed quite a few times already, and I happen to know the subject quite well. Integrated distributions (think Debian or Ubuntu) want you to run the pristine packages in their official repositories. They don't want you to run your own (and submit bugs when it fails), they don't want you to run a custom backport of a required new library. They want you to stay with a given version on a given OS, and to upgrade the whole package from time to time (Note: This does not affect that much RPM-based distributions, where taking a random RPM from a vendor site is apparently more accepted, due to most packages missing from the distro anyway). Deployers want to be able to run the exact version they want, on the exact OS they want. Use the base packages in the OS from a given reference point (generally Debian stable or Ubuntu LTS), and then deploy key packages at a chosen version, along with any dependency. Those goals are not compatible. So far we tried to reach both targets. We tightly integrated with the Ubuntu release under development. The absence of territorial maintainership in Ubuntu allowed us to efficiently push patches or bump versions on dependencies so that the future Ubuntu release would have all we need, and OpenStack packages could run directly on the pristine OS. We aligned the release schedules so that Ubuntu could actually ship the latest version of OpenStack packages in their official repositories. For all the other use cases, we would provide PPAs (last release, last milestone, trunk) x (lucid, maverick, natty, oneiric). This is very elegant, especially for ex-Ubuntu developers now working on upstream, like Soren or me. But I agree it has a few drawbacks, due to the fact it's pretty centered around Ubuntu: it makes the other distros second-class citizens, and it makes the "deployer" use case above a second-class citizen as well. The end result being that some critical deployers ended up not using our packages. We can bitch forever how wrong that is, and what they should do instead -- I don't think we'll change them. Monty's proposal is trying to address that. I think his proposal makes sense, but I also see how much we'll lose if we follow it. Reading between the lines, Monty's proposal is about losing the Ubuntu-integrated development, and providing our own packages (+ any needed dep) in our own repositories for a set of supported platforms. Then distributions are free to try to take those packages and ship them in their own repositories, or not. The first and most immediate drawback in my opinion is that we lose the very experienced Debian packaging team that we had set up. By closely working with Ubuntu upstream, we could leverage their manpower and experience to benefit our packaging. Bugs reported against Ubuntu packaging were in fact reported against our common work, and we got their bugfixes for free. If we move forward with this plan, the Ubuntu devs will retreat into being pure consumers (like with every other upstream), adding patches for their needs in their own version of the packaging. It's a loss that shouldn't be underestimated, especially by people that so far contributed nothing to the existing packaging. The second drawback is that without integration, the incentive to make the environments converge is limited. So far when we added a dependency there were discussions with Ubuntu as to what the common version should be. Now OpenStack will just pick what it prefers and shove it into its repos. Using packages from official repositories is more stable: their combination with the OS is more tested, and we benefit from OS bugfixes. So I expect the end result will be a less-integrated and more buggy environment. The last (and not least) drawback is that by following this plan, we become distributors. That means we have to care about support timeframes, point releases and security updates. We can no longer pretend that the downstream distributions will do it for us. This is a huge undertaking... who exactly is going to do that maintenance ? Is it really the best way to spend our time ? Last remark, to my fellow Frenchman Thomas, who sounds very supportive of Monty's proposal: I'm far from certain the end result would simplify your life. You'll still have to chase all dependency maintainers so that they align their version and patches with the ones OpenStack will require. Debian's use case is the same as Ubuntu's above -- you want people to use the main repository. Having an upstream ship its own overlapping debs should scare you. Unless your personal need, as an OpenStack user, is more on the deployer use case ? -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
