Hi, tl;dr: We'd likt to be able to update key cloud packages in Stable, as we consider them being just like Kernel drivers for the cloud.
Longer version: During a discussion in the debian-cd and debian-cloud list (cross-posts discussion), we all agreed that we would really like to have a more liberal approach to updating cloud high-profile packages (like cloud-init) in Stable. This message is an intend to discuss it outside of the closed sphere of the cloud people, with the more broad community. So, let me start and explain what the problem is. As you know, we don't allow changes to happen in Stable, as they may be disruptive and could cause unexpected issues. Though we do allow new kernel drivers to enter after Stable is released, because we want to be able to support more, and newer, hardware. It is my view (and probably the one of many others working on the cloud) that key software like cloud-init are kinds of drivers for the cloud, and that it is critical that they can be updated to support newer clouds. If we don't allow such updates in stable, then there are a few alternatives which can be used: * We can upload updates to stable-backports for example. But this means that, to keep packages updated, we should also add stable-backports to the image sources.list, which may be disruptive and not desirable. This also taints the cloud image as not being completely Debian Stable, which we all would prefer to avoid. * Another alternative is to use specific packages outside of Debian. Then the image becomes effectively a derivative of Debian, which is even worse than providing things through stable-backports. Also, we'd like to be able to call as many cloud images we support as "Debian Stable official cloud image", meaning that the images can't be tainted with packages from jessie-backports or Sid (and even less non-official Debian repos). We're currently releasing a cloud image for OpenStack, updated on each point release (which btw, could work on many other clouds if we take care of it properly). Meaning we're exposing this as a final artifact we're publishing, just like installer ISO. And it's state is currently not as good as we wish it could be. So, basically, any option besides updating Stable is not satisfying. Of course, we'd like to keep changes as minimal as possible. Though even doing that, it is very difficult to convince the release team. See for example this bug entry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789214 tl;dr: We're asking to add some .service files to cloud-init in stable, because the way systemd schedules things with initv scripts, the order is just wrong, and things may break. On a vanilla OpenStack image, that's fine, but as soon as you add new daemons and services, it starts to show. So the only way to fix things is to get the .service files added to Jessie. The issue has been pending since the 19th of June, with still no decision from the release team. And this is a very trivial fix that we've been proposing. I also do understand that the reason why we don't have a release team decision on this bug is probably because they are very busy, and that it's not very easy to understand what the problem is. Never the less, we'd still like to have a resolution for this problem. Also, we'd like to be able to ask for more, like adding support for clouds which we don't support yet (for example: Azure). This would mean much bigger patches to cloud-init, and even probably upgrades to a higher version of it. Of course, before asking for such changes, we would do extensive testing on all supported platforms. Having a set of automated tests is also currently discussed at debian-cloud@l.d.o. It is my strong opinion that we should define this required set of tests (meaning we'd define which platform we want to strongly support), and not allow any update if these tests didn't pass. Your thoughts everyone? Cheers, Thomas Goirand (zigo)