Re: official images status quo
Hi Zack,
On Sun, May 12, 2013 at 4:34 PM, Stefano Zacchiroli <zack@debian.org> 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.
No need - I was actually referring to my own comments as "petty
quibbling", not your questions. :) The ways I thought the EC2 image
deviate from what might be official from Debian's perspective, even if
they were real, were so small they didn't bother me, so my points felt
petty to me even while they seemed to be the accurate answers to your
questions.
> 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.
I didn't actually say or mean that - I said "most or all" [of the
three public cloud image types] seemed not to qualify as "official
Debian". The EC2 images are the ones which I was least sure about, and
indeed they seem either official or quite close to it. This is much
less obvious for the other two. I was also making my comment in
reference to Lucas' original definition (revisions to that hadn't been
shared yet), and the overall focus of my comment was "let's
communicate officially even though they aren't official images, since
we already do for the unofficial Debian ISOs with firmware". We agree
official communication is totally reasonable.
The Google Compute Engine images have a few issues to address before
they might qualify as official from Debian's perspective, though I'm
pleased that they're close enough to be called Debian. As for Windows
Azure, http://wiki.debian.org/Cloud/WindowsAzureImage makes it clear
that to follow the Azure build instructions, you have to follow
directions maintained by Joyent in their GitHub space to compile a
non-Debian version of Node.js, after which you use Node.js's package
manager npm to obtain azure-cli from non-Debian repositories. This
seems like it fails any reasonable definition of Debian maintenance of
build tools. Some might also be concerned by the requirement for Azure
credentials to build an image.
> From this sub-thread, which I consider quite productive in fact, I think
> we can conclude that at least the EC2 images "roughly qualify".
The EC2 images definitely roughly qualify, which is why I felt like I
was engaging in "petty quibbling" by focusing on the "roughly" when
you asked why they might not strictly qualify. James, Anders et al
have done great work.
> There are things that can be done better, certainly, and in particular:
> [...]
> 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.
I agree it seems fine to me at that point, though Lucas hasn't yet
said in this thread whether he is okay with Debian hosting an official
image build tool on GitHub instead of Alioth (see the wording he put
on his draft wiki page today and your reply on April 24 to ambiguity
in his original definition). It doesn't bother me strongly since every
git checkout is a complete copy of the repository, so if GitHub were
to vanish we'd just have to upload somewhere else. My guess is Lucas
finds this non-ideal but acceptable (me too), even though he hasn't
said so.
So, yes, "seems mostly or entirely fine to me, with somewhere between
zero and few shortcomings depending on definitions, most of which are
minor and easily fixed if anyone cares." See why I found it
counterproductive to focus on that? :) We've all progressed the
discussion more usefully in other ways, and have also agreed from the
beginning of this tangent that we should provide official mention of
the public cloud Debian images, even the ones which aren't fully
official.
> 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.
My understanding of the Google Compute Engine images' official status
blockers are here:
http://wiki.debian.org/Cloud/GoogleComputeEngineImage (I partially
overhauled the page six days ago). Please add, remove, or change as
appropriate.
One goal my colleagues and I share for DebConf13 is to figure out a
path forward regarding the several packaging issues which works for
both Debian and Google. That's the kind of issue where in-person
discussion, mutual understanding, and collaboration can help a lot.
It's good at least that there are no freeness issues to address - all
of that software is already under a suitable license.
I haven't examined the Azure images closely and don't know what other
blockers might exist.
> > 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.
Yup, sounds like we agree.
- Jimmy
Reply to: