git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, "Elijah Newren" <newren@gmail.com>,
	"Jeff King" <peff@peff.net>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Subject: proto v2 fixes for maint (was Re: Preparing for a Git 2.26.3 release)
Date: Tue, 28 Apr 2020 10:25:09 -0700	[thread overview]
Message-ID: <xmqq7dxz4j62.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200428055514.GB201501@google.com> (Jonathan Nieder's message of "Mon, 27 Apr 2020 22:55:14 -0700")

Jonathan Nieder <jrnieder@gmail.com> writes:

> Since then we've heard about a few related (non-security) regressions.
> I'd like to avoid giving people an excuse not to upgrade, so this
> morning[1] I promised a discussion of what I'd like to see in a 2.26.3
> release to help with that.

Thanks for starting this.  

I'll have chances to comment on other areas you listed, but since
I've answered on v2-proto stuff to somebody else already...

> The protocol version change was painful for users that fetch in the
> same repo from linux-next and other linux remotes[5].  The problem has
> been isolated and fixed, so we could either apply the revert or apply
> the fixes[6].

The demote patch hasn't even hit 'master'.  

My preference is to merge the demotion down to 'master' and 'maint'
while merging down this fix to 'next' and to 'master'.

And immediately revert the demotion on 'master', which will make the
tip of 'master' with v2 as the default, with "this" fix.

That way, those who want to help us polish the code further for the
next release would use v2 as default with the proposed fix for this
breakage and can hunt for other breakages in v2, while those on the
maintenance track (and v2.26.3 JNeider wants to see happen soon)
would revert to the original protocol as default.

In short, my preference is to ship 2.26.3 with the "demote v2 from
default", and hopefully try 2.27 with "v2 with negotiation fix" and
hope people won't find any other remaining glitches in 2.27.  After
that, we may want to merge the negotiation fix down to 2.26.x track
but I am not comfortable merging it in a release on the maintenance
track with the timeframe we seem to be talking about (i.e. a few
weeks, presumably).




  parent reply	other threads:[~2020-04-28 17:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  5:55 Preparing for a Git 2.26.3 release Jonathan Nieder
2020-04-28  6:22 ` Elijah Newren
2020-04-28 17:25 ` Junio C Hamano [this message]
2020-04-28 18:16   ` proto v2 fixes for maint (was Re: Preparing for a Git 2.26.3 release) Michal Suchánek
2020-04-28 18:19   ` Junio C Hamano
2020-04-29  5:56   ` Jonathan Nieder
2020-05-08 22:26 ` Preparing for a Git 2.26.3 release Junio C Hamano
2020-05-09  7:07   ` Johannes Schindelin
2020-05-09 17:11     ` Junio C Hamano

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=xmqq7dxz4j62.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).