Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 17 Nov 2021 17:59:48 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I tried to point out the downsides: the change is not really trivial,
> > and therefore will have fallout, as always happens with such changes.
> > And we will have to deal with that fallout.  Of course, since we are
> > always overly optimistic and hope there will be no unintended
> > consequences, we always tend to underestimate the downsides.
> 
> I understand your general concern, as with any code change, but I don't
> agree with the conclusion that we must not make this particular change.

Unfortunately, you don't say anything to explain why you "don't agree
with the conclusion", although you "understand my general concern".
Without explaining that, we are just reiterating the same arguments
over and over again.

This is a project-management issue, it has to do with a decision
whether a particular problem justifies the risks of a proposed
solution.  It's fundamentally a judgment call, and my judgment is that
the problem, such as it is, doesn't justify the risks.  If you want to
try to convince me to change my mind, you must provide arguments on
this level.  It isn't easy, because such judgments are very objective
and depend on our experiences, which are probably very different.  But
that's the only way of having a meaningful discussion of this issue,
and just repeating your disagreement in the face of my concerns
doesn't add anything useful to the discussion and certainly doesn't
give me anything to think about that I didn't already consider.

> I expect that there will be fallout only in code that assumes that an
> etc/NEWS file exists.  (Creating the symlink on GNU/Linux is mostly just
> convenience and not a proper solution, IMO.)
> 
> I think I covered most such cases in my patch, but of course I might
> have missed a few.  Having reviewed many (most? all?) such cases in our
> tree though, I very seriously doubt that any of it will be hard to
> change.

Like I said: we are always overly-optimistic about our abilities to
expect the unexpected.  We've been proven wrong many times, but we
still insist on hoping that this won't happen the next time.  How do
you reconcile these two and arrive at the (optimistic) conclusion that
this time will be different?  You don't say.

> It is a trivial case of: point it to NEWS.NN if NEWS doesn't
> exist.  You can see some examples in my latest patch.  Any such changes
> should be small and localized.

Yes.  Unless the unintended happens.  We are talking about risk
management, not about the specific technical solution you propose.
The useful arguments should compare the risks in the current situation
vs the risks of what could happen if we install your changes.

> > For non-problems such as this one, changes like this are just waste of
> > time and energy.  VCS is a tool, a means to an end; let's not make
> > changes in our code and create opportunity for subtle bugs just
> > because people rarely make VCS-related mistakes.
> 
> This is just one thread of many that we have had about the issues this
> has caused over the years.  We would arrive at the exact same conclusion
> whether or not this latest incident had happened or not.  In fact, we
> discussed it just the other week as well, in the thread where Glenn said
> he won't be doing the merges.  Sweeping it under the rug by calling it a
> "non-problem" is no solution at all.

What problem are you talking about?  Glenn wrote that code when he was
the only person who did the merges regularly, so it is a small wonder
that some of that doesn't work on other systems, especially on mine.
The reasons for that were identified and I have a local fix for it,
which I hope to test when I get the chance (some merge where NEWS is
involved).  That's it.  Following your optimism, I can likely say that
this problem is solved for good, and will never happen again.  So why
keep insisting that it exists?

IOW, what we had was a (relatively minor) fallout from passing the
responsibilities from one person to others.  This is behind us, so any
changes at this point look entirely unnecessary to me.

> The real reasons for wanting to fix this real problem are:
> 
> - It destroys our git history for the NEWS.NN file every time we cut a
>   release branch.
> 
> - It makes merging hard and error-prone.
> 
> - It really is an abuse of git when we could instead use it to our
>   advantage.  (There is no need to maintain custom code for a "merge"
>   that still leaves history broken when we could just let git do it.)
> 
> I propose that instead of fixing bugs in a fundamentally broken and
> wrong solution, we just do the right thing.  We will have fewer bugs to
> fix in the long run, and there are important advantages.

We have been over this already.  You are repeating arguments that were
voiced before, and I already considered all of those arguments before
I made up my mind.  How can I explain to you that reiterating them
will not change anything?  I tried explaining that many times in many
different ways, and I still fail to get my point through.  I tried
above one more time, in the(optimistic) hope that this time I will
succeed ;-)