On Sun, May 12, 2013 at 04:01:42PM -0400, Jimmy Kaplowitz wrote: > but honestly I'm not all that eager to continue what feels like petty > quibbling about the status quo since we all want the same basic > outcome here and nobody's acting in bad faith. Lucas's original > wording was AIUI not intended as a final judgment but as a starting > point. I've no idea why you took it that way, but I can assure you that I had very productive reasons to ask the questions I've asked, far from being "petty quibbling". If I expressed myself badly, giving you that impression, I apologize. So, what I've had in mind since very long time (as readers of this list know) is to advertise more broadly than we currently have done the "official" images we have. Therefore the reasons for my questions was to understand if, as you seemed to believe, none of the current images we currently have qualify for some official communication by the project. From this sub-thread, which I consider quite productive in fact, I think we can conclude that at least the EC2 images "roughly qualify". There are things that can be done better, certainly, and in particular: - the used euca2ools version (Anders, if you've a moment, can you explain if there are blockers that stop you from using one of the euca2ools version available in Debian, and in particular version 2.0.2-1 which is now in Debian stable) - the boto patch pulled from a BTS: is there any reason not to at least copy that patch in the build-debian-cloud repo? I think that would be an improvement and, actually, not that different from our usual practices (we do routinely embed 3rd party patches in package source packages) Do we agree that, once the above is done, the EC2 images would be fine for being Debian-stamped? Note that I do agree that having a proper *package* of build-debian-cloud would be even better, but I note that that's a higher quality standard than the rest of the Debian toolchain, which IMHO shouldn't be a blocker. Now, that's for the EC2 images, only because I'm a little bit more familiar with them than with the other ones. I'd love if people familiar with Azure and GCE images can do similar analyses and report here, at least what the major blockers wrt the criteria as we understand them up to now. Once we have a better understanding of the blockers, probably, it would be useful to report them as bugs against cloud.d.o. > It's probably more productive to refine the list of requirements Lucas > has kindly recorded in the wiki, maybe culminating in a discussion/BoF > at DC13, and to work to address outstanding issues. Any email > pre-discussion should probably be under a more descriptive subject > than "Adding cloud-init in the next Wheezy point release", too. :) I totally agree that would be useful as well. Feel free to start a thread on that, I'll be happy to participate :-) FWIW, I think that benchmarking the current images against our current understanding of the criteria (as I propose above) would actually be synergistic with what you propose here. 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