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

[Thomas Uhle <thomas.uhle@mailbox.tu-dresden.de>]

On Fri, 7 Nov 2025, Junio C Hamano wrote:

> 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.

I agree.  Fair enough.


> 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.

Understood.


> 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.

You are right though.  I have just thought that it might be good to 
have all the three commits for the update of the Makefiles in 
contrib/credential "in one go".  Yet, this is by far not comparable 
to those other cases.  Thanks for your explanations!

Best regards,

Thomas Uhle