Re: Sources for 3.18-rc1 not uploaded

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 21, 2014, 18:59 UTC
Message-ID: <xmqqoat5z1sh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54459E49.3040908@linuxfoundation.org>

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

Show 27 quoted lines

> On 20/10/14 06:28 PM, brian m. carlson wrote:
>>> Junio, quite frankly, I don't think that that fix was a good idea. I'd
>>> > suggest having a *separate* umask for the pax headers, so that we do
>>> > not  break this long-lasting stability of "git archive" output in ways
>>> > that are unfixable and not compatible. kernel.org has relied (for a
>>> > *long* time) on being able to just upload the signature of the
>>> > resulting tar-file, because both sides can generate the same tar-fiel
>>> > bit-for-bit.
>> It sounds like kernel.org has a bug, then.  Perhaps that's the
>> appropriate place to fix the issue.
>
> It's not a bug, it's a feature (TM). KUP relies on git-archive's ability
> to create identical tar archives across platforms and versions. The
> benefit is that Linus or Greg can create a detached PGP signature
> against a tarball created from "git archive [tag]" on their system, and
> just tell kup to create the same archive remotely, thus saving them the
> trouble of uploading 80Mb each time they cut a release.
>
> With their frequent travel to places where upload bandwidth is both slow
> and unreliable, this ability to not have to upload hundreds of Mbs each
> time they cut a release is very handy and certainly helps keep kernel
> releases on schedule.
>
> So, while it's fair to point out that git-archive was never intended to
> always create bit-for-bit identical outputs, it would be *very nice* if
> this remained in place, as at least one large-ish deployment (us) finds
> it really handy.

While I agree that it is a nice "feature", I wish KUP folks thought more about what should happen when the archive output _must_ change when a more serious bug is discovered, and coordinated with us better.

During a period where older and buggy versions of "git archive" are used by some uploaders while a new version is used by others, KUP could:

 - avail itself to a version (or versions) of "git archive" so that
   it can recreate both older and newer output;

 - upon receiving a tarball and signature, try recreating newer
   output and see if signature matches, and when the signature does
   not match, recreate older output and try again.

And we could supply "git archive --compatible=v1.7" option in the newer version if that is easier on KUP folks than having to keep multiple installations of versions of "git archive" around.

While I am on the topic of KUP, one feature I wish, which is the only thing that is preventing me from updating the preformatted documentation https://www.kernel.org/pub/software/scm/git/docs/, is to allow me to upload a single tarball and extract it at one location (e.g. /pub/software/scm/git/docs/) while removing existing files in that location (i.e. removing deleted files). Where do I file such a feature request?