Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 27, 2018, 07:02 UTC
Message-ID: <nycvar.QRO.7.76.6.1804270857260.72@tvgsbejvaqbjf.bet>
In-Reply-To: <4d0bd1a2-2f51-4a11-7e31-1e1ac5213c51@gmail.com>

Hi,

On Thu, 26 Apr 2018, Derrick Stolee wrote:

> On 4/25/2018 1:43 PM, Brandon Williams wrote:
> > On 04/25, Ævar Arnfjörð Bjarmason wrote:
> > > > * bw/protocol-v2 (2018-03-15) 35 commits
> > > >   (merged to 'next' on 2018-04-11 at 23ee234a2c)

[... snippppp ...]

Show 33 quoted lines

> > > >   (this branch is used by bw/server-options.)
> > > >
> > > >   The beginning of the next-gen transfer protocol.
> > > >
> > > >   Will cook in 'next'.
> > >
> > > With a month & 10 days of no updates & this looking stable it would
> > > be great to have it in master sooner than later to build on top of
> > > it in the 2.18 window.
> >
> > I personally think that this series is ready to graduate to master but
> > I mentioned to Junio off-list that it might be a good idea to wait
> > until it has undergone a little more stress testing.  We've been in
> > the process of trying to get this rolled out to our internal server
> > but due to a few roadblocks and people being out of the office its
> > taken a bit longer than I would have liked to get it up and running.
> > I'm hoping in another few days/a week I'll have some more data on live
> > traffic.  At that point I think I'll be more convinced that it will be
> > safe to merge it.
> >
> > I may be overly cautions but I'm hoping that we can get this right
> > without needing to do another protocol version bump for a very long
> > time.  Technically using v2 is hidden behind an "experimental" config
> > flag so we should still be able to tweak it after the fact if we
> > absolutely needed to, but I'd like to avoid that if necessary.
> 
> There's no testing better than production. I think if we have an
> opportunity to test with realistic traffic, we should take advantage.
> 
> But I also agree that this series looks stable.
> 
> I realize it's hard to communicate both "this series is ready to merge" and "I
> appreciate your caution."

To add to Stolee's comment: in our (day job) team, we are huge fans of "Feature Flags". We blog plenty about it, GitHub uses it in their Scientist approach, and even here in the Git project, we managed to use the paradigm: remember the transition from the scripted version of `difftool` to the builtin version? That was also done via a Feature Flag.

In the same vein, I would treat your config setting as a Feature Flag, and I would be very much in favor of having the code in production, with that feature flag defaulting to "off", and with a description that tells people very clearly that not only the flag is experimental, but that we might need to change the protocol, still, before v2 goes final.

I would then add an entry to Git for Windows' installer's "Experimental Options" section, to give it a bit more exposure (mainly to verify that the v2 client <-> v1 server connection works flawlessly), also as opt-in.

How does that sound?

Ciao, Dscho