From: Thomas Uhle Date: Sun, 09 Nov 2025 11:45:43 GMT Subject: Re: [PATCH] wincred: align Makefile with other Makefiles in contrib Message-ID: In-Reply-To: On Fri, 7 Nov 2025, Junio C Hamano wrote: > Thomas Uhle 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