All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	infra-steering@kernel.org, Git Mailing List <git@vger.kernel.org>
Subject: Re: Sources for 3.18-rc1 not uploaded
Date: Tue, 21 Oct 2014 11:59:58 -0700	[thread overview]
Message-ID: <xmqqoat5z1sh.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54459E49.3040908@linuxfoundation.org> (Konstantin Ryabitsev's message of "Mon, 20 Oct 2014 19:44:09 -0400")

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> 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?

      reply	other threads:[~2014-10-21 19:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20141020115943.GA27144@gmail.com>
2014-10-20 15:25 ` Sources for 3.18-rc1 not uploaded Linus Torvalds
2014-10-20 18:28   ` Junio C Hamano
2014-10-20 18:37     ` Konstantin Ryabitsev
2014-10-20 19:43       ` Junio C Hamano
2014-10-20 21:52       ` Greg KH
2014-10-20 22:28   ` brian m. carlson
2014-10-20 23:17     ` Linus Torvalds
2014-10-21  8:08       ` Michael J Gruber
2014-10-21 16:25         ` Linus Torvalds
2014-10-21 17:25           ` David Kastrup
2014-10-21 18:14         ` Junio C Hamano
2014-10-22  9:42           ` Michael J Gruber
2014-10-23  1:09             ` brian m. carlson
2014-10-26 18:59               ` René Scharfe
2014-10-26 21:15                 ` brian m. carlson
2014-10-27 20:19                 ` Junio C Hamano
2014-10-20 23:44     ` Konstantin Ryabitsev
2014-10-21 18:59       ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqoat5z1sh.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=infra-steering@kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.