Re: Status GCE images and trademark (was Please let's not talk about "clouds")
Generally == jimmy here.
There are a few issues here from Google's perspective, that I'm hoping
we can figure out how to work out (Jimmy and I are coming to Debconf
at the very least to work out, but it'd be great to make progress
before then too.
>From Google's perspective, there are a few issues we don't yet know
how to solve:
1) As our online services change (rapidly), it's important to get
our customers new versions of our tools quickly and easily. It's
terrible for customers to get an N-month-old-version of our tools in a
Debian-6 or Debian-7 repo, and try to use that. Our current solution
to that problem is to build and push images every month or so. We'd
*love* a mechanism wherein we can push new versions of our tools to
official debian archives every month or two...
2) gsutil has an array of c++ and python dependencies that are
available in Debian-6, but not with high-enough versions of those
dependencies. We have a binary-only debian package that installs all
the stuff necessary here, but it's unclear to us whether this is "good
enough" for inclusion in official Debian repos. Our .tar.gz version
takes these dependencies and includes them essentially "statically
linked" in the gsutil installation directory, which is a little
unconventional as well.
3) Really, focusing on gsutil and gcutil are a little narrow-minded.
What we at Google *really* want, is a good understanding of the
process and ideal mechanism to cook those artifacts that integrates
with Google build tools and with Debian's release tools. Then we can
standardize all our Google properties and use this mechanism, and make
Debian and Google "tier one" partners for releasing software.
4) More deeply, beyond just those tools, there are several bugs
we've found in Debian OS, which lead to highly degraded network
performance, and what looks to be massive CPU starvation in cloud
environments. We want to fix this problem in the Debian-6 and
Debian-7 images we provide but the process to do that is still unclear
Really, our goal here is to do The Right Thing. The problem is that
from our perspective, it's a discussion that is going to take some
time. But we're eager to have that discussion.
On Thu, May 16, 2013 at 8:34 AM, Jimmy Kaplowitz <email@example.com> wrote:
> [Adding my colleague to the thread]
> Hi Yaroslav,
> On Thu, May 16, 2013 at 11:20 AM, Yaroslav Halchenko <firstname.lastname@example.org> wrote:
>> Hi Jimmy,
>> Congrats on the launch! I have a little comment regarding one of your previous
>> posts where I got surprised that noone seems have expressed a similar line of
>> On Mon, 22 Apr 2013, Jimmy Kaplowitz wrote:
>>> 2) As I understand it, people in Debian are already packaging
>>> build-debian-cloud (f/k/a ec2debian-build-ami) for jessie. This is great.
>>> While gcutil and gsutil are free software, the pace of development is such
>>> that more thought is probably warranted on what the ideal situation is for
>>> their packaging and where such packaging would live. If David and/or I
>>> make it to DebConf13, this could be one of many fruitful topics of
>>> discussion. As with point 1, we're hoping to publicize these quite soon,
>>> so any packaging would necessarily happen some time after we properly
>>> announce these and gain users, not before.
>> to me it reads like:
>> we first release a car with a square steering wheel and when we announce
>> this new model and gain new users we will make it easier for them by making it
>> gcutil's Changelog suggests that it had been in development/release for a
>> $> grep release CHANGELOG
>> Release 1.8.0 (release date: 2013-05-15):
>> Release 1.7.2 (release date: 2013-03-11):
>> Release 1.2.0 (release date: 2012-08-28):
>> and I really see only disadvantages of having no publicly available (preferably
>> in Debian proper) Debian packages of the tool. It could have been blocked from
>> propagating into jessie if you care not to have a "releasable" version.
>> so really -- why not have it packaged and uploaded (like yesterday)?
> All of us see disadvantages to the status quo, no disagreement there.
> I'll use a similar analogy to yours - the situation is more like
> fitting a square peg into a round hole, but to correct the shape of
> the peg, we have to figure out how to round the edges without damaging
> Less metaphorically, there are technical, release engineering, and
> cultural issues to figure out to do this right (I'm the only one
> closely involved with this effort who comes from a Debian community
> background and the typical concerns and workflow of a company are
> quite different). Everyone involved wants to resolve these issues,
> happily, and doing so is a core reason one or two of them will be
> joining me at DebConf this year. Their basic reason for attending is
> to figure out how to collaborate best with Debian, very much including
> packaging issues.
> So, the summary is, "you make a good point, to which the resolution
> will need a bit more back-and-forth, but we're all interested in
> getting there."
> One thing to note in the meantime: the main thing missing is Debian
> packages, not public releases or source code. For gcutil that's all
> available via https://code.google.com/p/google-compute-engine-tools/ ,
> and for gsutil at https://github.com/GoogleCloudPlatform/gsutil/ .
> - Jimmy