git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Junio C Hamano
Message 7 of 7 in “wincred: align Makefile with other Makefiles in contrib”
  1. wincred: align Makefile with other Makefiles in contribThomas Uhle, Nov 5, 2025
  2. Junio C HamanoNov 6, 2025
  3. Johannes SchindelinNov 6, 2025
  4. Junio C HamanoNov 6, 2025
  5. Thomas UhleNov 7, 2025
  6. Junio C HamanoNov 7, 2025
  7. Thomas UhleNov 9, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.