[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

official images status quo

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

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.

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

Reply to: