Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano <gitster@pobox.com>]

Ondrej Pohorelsky <opohorel@redhat.com> writes:

> Hi, I just want to weight in from the downstream maintainer POV.
> We've been carrying the patches Johannes has created in Fedora, CentOS
> and RHEL for at least half a year now.
> The only change I did is to make the new behavior opt-in by default
> and give the RHEL customers a release note explaining it.

Thanks for your great input.  FWIW, I do not think anybody around
here is against "opt-in with a note" approach at all.

> I think the patches proposed are making sense, and they should be
> merged. Even having them as opt-in is better than not having them
> merged at all.

I do not think anybody disagrees with this sentiment.  Back when the
patches originally was discussed on the public list here, nobody was
against adding it as an _optional_ feature to filter some byte
sequences out of the end-user's data stream, and the review comments
that led to the topic marked to be "expecting a reroll", if I recall
correctly, were all about "why would we make this on by default?"
Peff's message that reignited the topic this time around is also
about the same.

We are still hearing from Dscho that he cannot think of a scenario
where making this mandatory with opt-out would break existing
legitimate setup people may have (I am paraphrasing [*]), but I
think that is aiming in the wrong direction.  It does not matter if
you consider the approach your users take is "broken by design"; as
long as it works for them in their (limited) settings, it is a valid
arrangement to send arbitrary byte sequence over the sideband even
it happens to include ANSI escapes and other "curiosities".  We have
in no position to unilaterally break them, telling them that we left
a way open for them to disable.  That is not how to deliver features.

I strongly suspect that the reason why you made "The only
change---opt-in by default" is from the same reasoning as above.  Do
not break end-users' set-up.  As long as it works for them, it is
not "broken by design" to them, and it is irresponsible to break
their set-up.

But an opt-in way to filter suspicious byte sequences is a good
thing, as such a mechanism did not exist before.

So in short, yes, everybody around here agrees with you that the
feature as an opt-in is a great addition.


[Footnote]

 * Here is from <c0af9072-cf21-a7e2-5b78-eb70217b462c@gmx.de>
   without my paraphrasing.

   """Can you help me understand how these existing use cases (which
   are not actually in wide-spread use) aren't broken by design, given
   that they have no chance to ensure that their ANSI sequences go to
   an actual terminal that can understand those sequences?"""