Re: Train station analogy, was Re: [PATCH v3 00/15] [RFC] Upstreaming the Scalar command

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Sep 14 2021, Johannes Schindelin wrote:

> Hi Ævar,
>
> On Tue, 14 Sep 2021, Ævar Arnfjörð Bjarmason wrote:
>
>> On Mon, Sep 13 2021, Johannes Schindelin wrote:
>>
>> > On Mon, 13 Sep 2021, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> On Thu, Sep 09 2021, Ævar Arnfjörð Bjarmason wrote:
>> >>
>> >> > In the summary I had on v1->v2 points 1-3 are for v2->v3,
>> >> > respectively, outstanding, addressed, outstanding:
>> >> >
>> >> >     https://lore.kernel.org/git/877dfupl7o.fsf@evledraar.gmail.com/
>> >> >
>> >> > In addition the discussion ending here:
>> >> > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2109082112270.55@tvgsbejvaqbjf.bet/
>> >> >
>> >> > For that point: I think it's fair enough not to properly handle the
>> >> > cleanup case in "scalar clone", but perhaps add a note in the
>> >> > commit message that unlike "git clone" this is known not to clean
>> >> > after itself properly on ctrl+c?
>> >>
>> >> Seeing [1] about the planned re-roll I have the above a shot a few
>> >> days ago, see the original discussion at [2] (indirectly linked
>> >> above).
>> >
>> > There is a good reason why I did not engage in that tangent about
>> > deviating from the established `contrib/*/Makefile` paradigm: I find
>> > it particularly unrelated to what this here patch series is trying to
>> > accomplish, and I cannot bring myself to be interested in the proposed
>> > build system changes, either, because I do not see any benefit in the
>> > changes, only downsides.
>> >
>> > I find the distraction unnecessary.
>>
>> Perhaps I'm reading too much between the lines here, so forgive any
>> undue knee-jerk reaction.
>
> Okay, let's try an analogy.
>
> Imagine that a person is asking for directions to the train station. And
> the other person is replying by asking "did you know that this train
> station was built in 1878? It is actually quite interesting a story...
> [and then goes on to describe the history and what excites them about
> it]". Now, the first person tries again to ask for directions, again does
> not get an answer to that question, and is slowly starting to look at
> their watch. The second person, being completely oblivious to all of this,
> goes on with their wonderful story about the train station and its
> cultural heritage. So the first person walks a bit further to ask a third
> person, but the second person is not done yet and says "but you haven't
> heard me out! That's disrespectful!".

To be clear that's not what I said or meant. I wasn't saying you had to
exhaustively hear out some argument or participate in a discussion
you're not interested in.

I am saying that if you're soliciting feedback and you get some, and the
person giving you the feedback sends you pings back, as I did here:

    https://lore.kernel.org/git/871r6axban.fsf@evledraar.gmail.com/
    https://lore.kernel.org/git/87mtoxwt63.fsf@evledraar.gmail.com/
    https://lore.kernel.org/git/877dfupl7o.fsf@evledraar.gmail.com/
    https://lore.kernel.org/git/87r1dydp4m.fsf@evledraar.gmail.com/

That it would be nice to at least reply with some brief comment to the
effect that you're not personally interested in improving this area.

Now, shortly after you send this you re-rolled the v3
(https://lore.kernel.org/git/pull.1005.v4.git.1631630356.gitgitgadget@gmail.com/)
with a note of:

 * Removed the [RFC] prefix because I did not hear any objections against
   putting this into contrib/.

I don't know if you wrote that after this reply, or really didn't see
any of above, but that's a really inaccurate/misleading comment
considering that context.

> Just imagine for a minute how you would feel if you were the first person.
>
> And that is how I feel asking for reviews about the Scalar patch series
> and then being forcefully dragged into that tangent about the build
> process.
>
> I find the well-established paradigm to keep contrib/'s build procedures
> as confined to their own directory as possible the most reasonable way to
> handle the build by virtue of _not_ polluting the top-level Makefile
> unnecessarily. All of your objections strike me simply as personal
> viewpoints, not as technical arguments, and they fail to address this
> "pollution of the top-level Makefile" problem. I therefore strongly
> disagree with your suggestion that the build system should be changed, I
> would even argue that your suggestion should been dismissed on purely
> technical grounds, and I wish you hadn't forced me to say this as
> forcefully.
>
> And even if I looked more favorably on your suggestion to change the build
> procedure, I find this distraction about the build as little constructive
> as the explanations about the train station's history above.

If we're indulging each other, here's my version of that train analogy:

We're in the business of selling a sugary drink that comes in a red can.

We've got a big factory with an attached train station, and all the
trains that move our product are also red.

Now, some of our customers want the new purple colored sugary drink
we've cooked up. A new purple factory's all set up for making them.

But for some reason the part of the business and distribution plans call
for building a new purple train station parallel to our existing one.

All purple sugary drinks are expected to be moved on purple trains, all
our conductors will need some slight re-training and switchover time to
flip-flop between red and purple trains. Issues with purple production
floors and purple workflows will need to be ironed out.

We did a survey of our customers and most of them weren't even aware
that there was such a thing as train. Or perhaps they've seen other
trains, but most haven't seen our trains.

Trains occasionally need field servicing, luckily our fleet of red
trains is set up to carry its own spare parts. Purple trains can only be
serviced with the assistance of a red train.

A product survey asking customers whether their enjoyment of the red or
purple sugary drinks might be impacted by the color of the train they
were shipped on only resulted in puzzled blank looks from the
participants.

The current state of the purple train station and its fleet of purple
trains is that it somewhat works with some hiccups. The currently built
purple train station omitted any sort of train track for leaving the
station though. It should be easy to add one, but...

The manager of the purple train project has been asked whether we can't
just have our red machines in our red factory make the purple sugary
drink, which we can then load on our fleet of red trains. Why do we need
a new parallel rail system when we really care about customers drinking
our delicious sugary drinks?

In case it's not obvious:

   {red,purple} sugary drink  = /usr/bin/git & /usr/bin/scalar
   {red,purple} train station = ./Makefile & ./contrib/scalar/Makefile
   train track for leaving the station = make install (AFAICT your
                                         current patches have no
                                         installation mechanism)

> Those
> suggestions do succeed in derailing the conversation about how Git could
> scale better, how Scalar _does_ teach Git how to scale better, and about
> how to teach Git itself more and more of Scalar's tricks.
>
> If you have ideas how to teach, say, `git clone` to perform a couple of
> Scalar's tricks, by all means, let's hear them, or even better, let's see
> those patches. If you want to change the build system, still, I cannot
> stop you from sending patches to that end to the Git mailing list, but
> please expect me to be uninterested in them in any way, and to prefer to
> spend my efforts to improve Git elsewhere. If you have other ideas how to
> improve on Scalar in a user-perceptible way, however, I am all ears again.
>
> I hope this clarifies it, without the need to read between the lines,
> Johannes

Whatever the end goal of the patches you're sending part of them is
proposing a given approach to go from A to B.

I find it odd to be claiming that the end-state is so important that we
can't spare time to discuss some of the implementation
details.

Particularly in this case, where I've sent a mostly working patch-on-top
which I think should be clear from context I'd be willing to finish up,
so it's not like it's just pointless nitpicking with no end-goal of a
code improvement in sight.