On 12 May 2013 22:34, Stefano Zacchiroli <[email protected]> wrote: > 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 . . . . . . . [email protected] . . . . 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 »
> 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 I had to check the source to figure out my original reasoning for that :-), it says: # We use euca2ools to communicate with AWS # The package in squeeze is v 1.2, which does not support EBS images Are we still concerned with bootstrapping *from* squeeze? Otherwise we can easily just use the one from the repo. > 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) No reason; not sure why I haven't done that long ago. I have to check if this is fixed in wheezy, maybe we can avoid it entirely, or simply fix it in the repo. If we do those things, we can install *everything* from the repo, no third-party stuff needed. Anders -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAMcOGXEgav0Fny6w2iooDu=om88qz1x94eyumbpkqulfn2s...@mail.gmail.com
