Re: [PATCH] wincred: align Makefile with other Makefiles in contrib
- From
Thomas Uhle <thomas.uhle@mailbox.tu-dresden.de>
- Date
- Nov 9, 2025, 11:45 UTC
- Message-ID
- <cef2a5b6-8133-0e5a-5523-80625d9d4671@mailbox.tu-dresden.de>
- In-Reply-To
- <xmqqwm41g605.fsf@gitster.g>
On Fri, 7 Nov 2025, Junio C Hamano wrote:
Show 15 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 22 quoted lines
> 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