Re: Status GCE images and trademark (was Please let's not talk about "clouds")
Yup, David summarized pretty well where the various Google Cloud teams
are coming from.
Regarding #4 specifically, our first plan is to work with the relevant
Debian maintainers and (where appropriate) oldstable/stable release
managers to get suitably minimal and noninvasive patches applied,
following the usual Debian processes as much as I can shepherd that
forward.
All of these things will need to be a multidirectional discussion with
various participants having their areas of familiarity and expertise,
and other areas where listening to other perspectives and needs will
be most productive. My individual role is somewhat in the middle here,
trying to help bridge gaps as well as doing some of the technical
work. I'm very happy that my colleagues want to do the right thing for
both Google's customers and Debian.
- Jimmy
On Thu, May 16, 2013 at 1:40 PM, David McWherter <cache@google.com> wrote:
> 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
> to us.
>
> 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.
>
> -david
>
> On Thu, May 16, 2013 at 8:34 AM, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
>> [Adding my colleague to the thread]
>>
>> Hi Yaroslav,
>>
>> On Thu, May 16, 2013 at 11:20 AM, Yaroslav Halchenko <yoh@debian.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
>>> thought:
>>>
>>> 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
>>> round...
>>>
>>> gcutil's Changelog suggests that it had been in development/release for a
>>> while:
>>>
>>> $> 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
>> it.
>>
>> 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
Reply to: