On Wed, Apr 24, 2013 at 02:54:36PM +0200, Lucas Nussbaum wrote: > First, Nothing below is a definitive answer, either positive or negative. > As you know, we don't have clear guidelines/policies for that question. > I'm trying to get a better understanding first, and I'm open to changing > my mind. :) Right, thanks for starting this. We sort of discussed this on this list for Amazon EC2 images, mainly because they've been the first major public cloud provider offering "official" Debian images. I mentioned "sort of" because the discussion had not been explicitly on "guidelines", but we did discuss blockers for publications here --- in particular I've raised a few of them. I try below to recast them as more general guideline points, for your (and this list) consideration. > For "official Debian images", I think that the list of requirements > should include at least: > A) the image includes only software available in Debian To be precise, I think this should be Debian *proper*, i.e. only the main archive. Moreover, I think contrib and non-free should *not* be enabled by default within the images. More generally, we have a lot of defaults in the Debian images we distribute for installation on actual hardware. To be thorough, we should review those defaults and decide which of them are a must for virtual images as well and which should be relaxed. But that would be a tedious exercise. So, as an alternative, we should probably expect that virtual images have the same content of non-virtual Debian images, and that differences should be explicitly approved (by whom? no idea :-)). This is very similar to what trademark policy usually require for any sort of product. I.e. if the product is "substantially equivalent" to what we call "Debian" elsewhere, then it can be called "Debian" by others (in this case: cloud marketplace vendors), otherwise it will need to be explicitly approved. An alternative would be to have a testsuite that should pass before being able to call something Debian. But we're nowhere near having something of the sort, and I don't think it'd be a quick exercise to do either. > B) the image generation process is controlled solely by Debian I'm not sure if "solely" is tenable. I think for instance at the need of cryptographically sign images, with keys available only to the public cloud vendors. (This is, in fact, very similar to Secure Boot situations.) We should probably expect that some steps are not redoable by Debian, as long as we can inspect the produced images, or something such. > C) the image is generated using tools available in Debian, or maintained > by Debian That is fine, but note that the "or maintained by Debian" is a very relevant "or". For instance, even only for traditional Debian images, we have a lot of the infrastructure we use to make Debian which is not part of Debian (e.g. dak). So, what does it mean "maintained by Debian"? Note for instance that Anders' scripts to produce both EC2 and GCE images are currently hosted in GitHub and that Anders is not a Debian Developer. I totally *love* his work :), and I'd like it to qualify for producing "official" images. Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature