Re: [PATCH] wincred: align Makefile with other Makefiles in contrib

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

Thomas Uhle <thomas.uhle@mailbox.tu-dresden.de> writes:

> Thank you!  Does this patch qualify for the final version 2.52.0 or is it 
> already too late?  And if it is the latter, wouldn't it make sense to have 
> it in an updated version 2.52.1?

Highly unlikely, I would suspect.

In general, after -rc1 gets tagged, nothing will become candidate
for the final release without a valid excuse.  One common reason is
that it is a bugfix for a regression that was introduced during the
cycle.  This clearly isn't one---the aspect of the wincred Makefile
your patch fixes haven't changed since ccfb5bda (wincred: add
install target, 2012-10-24).  People lived with that awkwardness for
13 years.  They can live with it a few more months just fine.

Those who _have_ been building wincred and installing it for their
own (or for their colleages) would have an established procedure to
work around the unusual arrangement the Makefile has (which you have
fixed), and changing it this close to the final release would only
add extra work on them, without helping anybody else.  A good time
to merge such a change is early in a fresh cycle, so that they have
longer preparation period to adjust their build infrastructure.

There are reasons we may want to have changes newly floated after
-rc1 got tagged; for example, I merged 8d716966 (ci: update
{download,upload}-artifact Action versions, 2025-11-06) after
tagging -rc1.  There were another CI fix merged immediately before
-rc1.

The benefit any late changes that get merged has to outweigh the
risks by a large margin, and CI changes like these have very small
blast radius even if it goes wrong (nobody other than our developers
would be affected, and they know what to do) while the damage
unfixed CI job can cause is larger (CI can deliberately stop to make
us realize that the service we rely on is being deprecated).

There also is a message typofix merged post -rc1, to correct new
messages that appeared during this cycle.  The output from the
programs before the release candidate were properly localizable, but
left unfixed, our translators need to translate typoed messages, and
then when the typofix hits 'master' later, they have to adjust their
translations by updating what original gets translated again.

Is there comparable justification why wincred/Makefile change has to
be in the upcoming release?  I do not think of any.