{"thread":{"id":"65464","subject":"[PATCH v2 2/4] ci: install cargo on Alpine","startedAt":"2026-04-09T22:44:37Z","lastAt":"2026-04-10T22:35:19Z","messageCount":14,"participants":["brian m. carlson","Derrick Stolee","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":4},"messages":[{"id":"541316","messageId":"20260409224434.1861422-2-sandals@crustytoothpaste.net","threadId":"65464","inReplyTo":"20260409224434.1861422-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 1/4] docs: update version with default Rust support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-09T22:44:31Z","receivedAt":"2026-04-09T22:44:36Z","isPatch":true,"body":"We missed the cut-off for Rust by default in 2.53, but we still can\nenable it by default for 2.54, so update our breaking changes document\naccordingly.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/BreakingChanges.adoc | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc\nindex f814450d2f..510ed98b65 100644\n--- a/Documentation/BreakingChanges.adoc\n+++ b/Documentation/BreakingChanges.adoc\n@@ -190,7 +190,7 @@ milestones for the introduction of Rust:\n 1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and\n disabled in our Makefile so that the project can sort out the initial\n infrastructure.\n-2. In Git 2.53, both build systems will default-enable support for Rust.\n+2. In Git 2.54, both build systems will default-enable support for Rust.\n Consequently, builds will break by default if Rust is not available on the\n build host. The use of Rust can still be explicitly disabled via build\n flags.\n"},{"id":"541317","messageId":"20260409224434.1861422-4-sandals@crustytoothpaste.net","threadId":"65464","inReplyTo":"20260409224434.1861422-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 3/4] Linux: link against libdl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-09T22:44:33Z","receivedAt":"2026-04-09T22:44:36Z","isPatch":true,"body":"Older versions of Rust on Linux, such as that used in Debian 11 in our\nCI, require linking against libdl. Were we linking with Cargo, this\nwould be included automatically, but since we're not, explicitly set it\nin the system-specific config.\n\nThis library is part of libc, so linking against it if it happens to be\nunnecessary will add no dependencies to the resulting binary. In\naddition, it is provided by both glibc and musl, so it should be\nportable to almost all Linux systems.\n\nSigned-off-by: brian m. carlson \n---\n config.mak.uname | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/config.mak.uname b/config.mak.uname\nindex ccb3f71881..7aab56c590 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -63,6 +63,7 @@ ifeq ($(uname_S),Linux)\n \tPROCFS_EXECUTABLE_PATH = /proc/self/exe\n \tHAVE_PLATFORM_PROCINFO = YesPlease\n \tCOMPAT_OBJS += compat/linux/procinfo.o\n+\tEXTLIBS += -ldl\n \t# centos7/rhel7 provides gcc 4.8.5 and zlib 1.2.7.\n ifneq ($(findstring .el7.,$(uname_R)),)\n \t\tBASIC_CFLAGS += -std=c99\n"},{"id":"541318","messageId":"20260409224434.1861422-1-sandals@crustytoothpaste.net","threadId":"65464","inReplyTo":null,"subject":"[PATCH v2 0/4] Enable Rust by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-09T22:44:30Z","receivedAt":"2026-04-09T22:44:36Z","isPatch":true,"body":"Our breaking changes document said that we would enable Rust support by\ndefault in Git 2.53, while still leaving the ability for it to be\ndisabled. Unfortunately, we forgot to do that and my time machine is\nbroken right now, so this series sets it up for Git 2.54.\n\nCI remains passing on GitHub Actions in v2.\n\nChanges since v1:\n\n* Move Cargo declaration to src/meson.rs.\n* Add a Meson build without Rust.\n* Remove `-Drust=enabled` for Meson, which is no longer needed.\n\nbrian m. carlson (4):\n docs: update version with default Rust support\n ci: install cargo on Alpine\n Linux: link against libdl\n Enable Rust by default\n\n Documentation/BreakingChanges.adoc | 2 +-\n Makefile | 10 +++++-----\n ci/install-dependencies.sh | 2 +-\n ci/lib.sh | 3 +++\n ci/run-build-and-tests.sh | 6 ++++--\n config.mak.uname | 1 +\n meson.build | 3 +--\n meson_options.txt | 2 +-\n src/meson.build | 1 +\n 9 files changed, 18 insertions(+), 12 deletions(-)\n\n"},{"id":"541319","messageId":"20260409224434.1861422-5-sandals@crustytoothpaste.net","threadId":"65464","inReplyTo":"20260409224434.1861422-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 4/4] Enable Rust by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-09T22:44:34Z","receivedAt":"2026-04-09T22:44:36Z","isPatch":true,"body":"Our breaking changes document says that we'll enable Rust by default in\nGit 2.54. Adjust the Makefile to switch the option from WITH_RUST to\nNO_RUST to enable it by default and update the help text accordingly.\nSimilarly, for Meson, enable the option by default and do not\nautomatically disable it if Cargo is missing, since the goal is to help\nusers find where they are likely to have problems in the future.\n\nUpdate our CI tests to swap out the single Linux job with Rust to a\nsingle job without, both for Makefile and Meson. Similarly, update the\nWindows Makefile job to not use Rust, while the Meson job (which does\nnot build with ci/lib.sh) will default to having it enabled.\n\nMove the check for Cargo in the Meson build because it is no longer\nneeded in the main script.\n\nSigned-off-by: brian m. carlson \n---\n Makefile | 10 +++++-----\n ci/lib.sh | 3 +++\n ci/run-build-and-tests.sh | 6 ++++--\n meson.build | 3 +--\n meson_options.txt | 2 +-\n src/meson.build | 1 +\n 6 files changed, 15 insertions(+), 10 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 5d22394c2e..945adb9aa5 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -498,9 +498,9 @@ include shared.mak\n #\n # == Optional Rust support ==\n #\n-# Define WITH_RUST if you want to include features and subsystems written in\n-# Rust into Git. For now, Rust is still an optional feature of the build\n-# process. With Git 3.0 though, Rust will always be enabled.\n+# Define NO_RUST if you want to disable features and subsystems written in Rust\n+# from being compiled into Git. For now, Rust is still an optional feature of\n+# the build process. With Git 3.0 though, Rust will always be enabled.\n #\n # Building Rust code requires Cargo.\n #\n@@ -1351,7 +1351,7 @@ LIB_OBJS += urlmatch.o\n LIB_OBJS += usage.o\n LIB_OBJS += userdiff.o\n LIB_OBJS += utf8.o\n-ifndef WITH_RUST\n+ifdef NO_RUST\n LIB_OBJS += varint.o\n endif\n LIB_OBJS += version.o\n@@ -1590,7 +1590,7 @@ endif\n ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND)\n ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)\n \n-ifdef WITH_RUST\n+ifndef NO_RUST\n BASIC_CFLAGS += -DWITH_RUST\n GITLIBS += $(RUST_LIB)\n ifeq ($(uname_S),Windows)\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 42a2b6a318..1cfc8c6efc 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -372,6 +372,9 @@ linux-asan-ubsan)\n osx-meson)\n \tMESONFLAGS=\"$MESONFLAGS -Dcredential_helpers=osxkeychain\"\n \t;;\n+windows-*)\n+\texport NO_RUST=UnfortunatelyYes\n+\t;;\n esac\n \n MAKEFLAGS=\"$MAKEFLAGS CC=${CC:-cc}\"\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 28cfe730ee..e2d783d90b 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -8,11 +8,12 @@\n export TEST_CONTRIB_TOO=yes\n \n case \"$jobname\" in\n+linux-musl-meson)\n+\tMESONFLAGS=\"$MESONFLAGS -Drust=disabled\"\n+\t;;\n fedora-breaking-changes-musl|linux-breaking-changes)\n \texport WITH_BREAKING_CHANGES=YesPlease\n-\texport WITH_RUST=YesPlease\n \tMESONFLAGS=\"$MESONFLAGS -Dbreaking_changes=true\"\n-\tMESONFLAGS=\"$MESONFLAGS -Drust=enabled\"\n \t;;\n linux-TEST-vars)\n \texport OPENSSL_SHA1_UNSAFE=YesPlease\n@@ -30,6 +31,7 @@ linux-TEST-vars)\n \texport GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1\n \t;;\n linux-clang)\n+\texport NO_RUST=UnfortunatelyYes\n \texport GIT_TEST_DEFAULT_HASH=sha1\n \t;;\n linux-sha256)\ndiff --git a/meson.build b/meson.build\nindex 8309942d18..deff129cf6 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -1745,8 +1745,7 @@ version_def_h = custom_target(\n )\n libgit_sources += version_def_h\n \n-cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))\n-rust_option = get_option('rust').disable_auto_if(not cargo.found())\n+rust_option = get_option('rust')\n if rust_option.allowed()\n subdir('src')\n libgit_c_args += '-DWITH_RUST'\ndiff --git a/meson_options.txt b/meson_options.txt\nindex 659cbb218f..80a8025f20 100644\n--- a/meson_options.txt\n+++ b/meson_options.txt\n@@ -77,7 +77,7 @@ option('zlib_backend', type: 'combo', choices: ['auto', 'zlib', 'zlib-ng'], valu\n # Build tweaks.\n option('breaking_changes', type: 'boolean', value: false,\n description: 'Enable upcoming breaking changes.')\n-option('rust', type: 'feature', value: 'auto',\n+option('rust', type: 'feature', value: 'enabled',\n description: 'Enable building with Rust.')\n option('macos_use_homebrew_gettext', type: 'boolean', value: true,\n description: 'Use gettext from Homebrew instead of the slightly-broken system-provided one.')\ndiff --git a/src/meson.build b/src/meson.build\nindex 45739957b4..41a4b231e6 100644\n--- a/src/meson.build\n+++ b/src/meson.build\n@@ -29,6 +29,7 @@ libgit_rs = custom_target('git_rs',\n )\n libgit_dependencies += declare_dependency(link_with: libgit_rs)\n \n+cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust'))\n if get_option('tests')\n test('rust', cargo,\n args: [\n"},{"id":"541315","messageId":"20260409224434.1861422-3-sandals@crustytoothpaste.net","threadId":"65464","inReplyTo":"20260409224434.1861422-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 2/4] ci: install cargo on Alpine","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-09T22:44:32Z","receivedAt":"2026-04-09T22:44:37Z","isPatch":true,"body":"We'll make Rust the default in a future commit, so be sure to install\nCargo (which will also install Rust) to prepare for that case.\n\nSigned-off-by: brian m. carlson \n---\n ci/install-dependencies.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex c55441d9df..10c3530d1a 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -29,7 +29,7 @@ alpine-*)\n \tapk add --update shadow sudo meson ninja-build gcc libc-dev curl-dev openssl-dev expat-dev gettext \\\n \t\tzlib-ng-dev pcre2-dev python3 musl-libintl perl-utils ncurses \\\n \t\tapache2 apache2-http2 apache2-proxy apache2-ssl apache2-webdav apr-util-dbd_sqlite3 \\\n-\t\tbash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty >/dev/null\n+\t\tbash cvs gnupg perl-cgi perl-dbd-sqlite perl-io-tty cargo >/dev/null\n \t;;\n fedora-*|almalinux-*)\n \tcase \"$jobname\" in\n"},{"id":"541365","messageId":"4efc4133-3726-4b9d-8f06-03c07d48af99@gmail.com","threadId":"65464","inReplyTo":"20260409224434.1861422-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-04-10T13:02:13Z","receivedAt":"2026-04-10T13:02:16Z","isPatch":true,"body":"On 4/9/2026 6:44 PM, brian m. carlson wrote:\n> Our breaking changes document said that we would enable Rust support by\n> default in Git 2.53, while still leaving the ability for it to be\n> disabled. Unfortunately, we forgot to do that and my time machine is\n> broken right now, so this series sets it up for Git 2.54.\n\nI'm glad you're remembering to help us follow through on this promise.\n\nHowever, I'm worried that we shouldn't do this change during the rc\nwindow for 2.54.0. Perhaps we could get a small patch that updates the\ndocs to say \"we really mean 2.55.0\" that lands in the 2.54.0 release,\nand then we merge the requirements for the build in the first batch\nafter the release.\n\nThis would give us a full release cycle to simmer with the requirement\ninstead of slipping it in for the last rc.\n\nThanks,\n-Stolee\n\n"},{"id":"541367","messageId":"xmqqa4varhod.fsf_-_@gitster.g","threadId":"65464","inReplyTo":"4efc4133-3726-4b9d-8f06-03c07d48af99@gmail.com","subject":"Re*: [PATCH v2 0/4] Enable Rust by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-10T14:52:50Z","receivedAt":"2026-04-10T14:52:52Z","isPatch":true,"body":"Derrick Stolee writes:\n\n> On 4/9/2026 6:44 PM, brian m. carlson wrote:\n>> Our breaking changes document said that we would enable Rust support by\n>> default in Git 2.53, while still leaving the ability for it to be\n>> disabled. Unfortunately, we forgot to do that and my time machine is\n>> broken right now, so this series sets it up for Git 2.54.\n>\n> I'm glad you're remembering to help us follow through on this promise.\n>\n> However, I'm worried that we shouldn't do this change during the rc\n> window for 2.54.0. Perhaps we could get a small patch that updates the\n> docs to say \"we really mean 2.55.0\" that lands in the 2.54.0 release,\n> and then we merge the requirements for the build in the first batch\n> after the release.\n>\n> This would give us a full release cycle to simmer with the requirement\n> instead of slipping it in for the last rc.\n\nYes, let's do that.\n\nI thought that leaving a bit of wiggle room like this:\n\n 2. In Git 2.55 (or later, if the codebase and the world is not yet ready by then),\n both build systems will default-enable support for Rust.\n\nmight not be a bad idea, but during the -rc period, simpler the better.\n\n----- >8 -----\nSubject: rust: we are way beyond 2.53\n\nEarlier we timelined that we'd tune our build procedures to build\nwith Rust by default in Git 2.53, but we are already in prerelease\nfreeze for 2.54 now. Update the BreakingChanges document to delay\nit until Git 2.55 (slated for the end of June 2026).\n\nNoticed-by: brian m. carlson \nHelped-by: Derrick Stolee \nSigned-off-by: Junio C Hamano \n---\n Documentation/BreakingChanges.adoc | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git c/Documentation/BreakingChanges.adoc w/Documentation/BreakingChanges.adoc\nindex f814450d2f..af59c43f42 100644\n--- c/Documentation/BreakingChanges.adoc\n+++ w/Documentation/BreakingChanges.adoc\n@@ -190,7 +190,7 @@ milestones for the introduction of Rust:\n 1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and\n disabled in our Makefile so that the project can sort out the initial\n infrastructure.\n-2. In Git 2.53, both build systems will default-enable support for Rust.\n+2. In Git 2.55, both build systems will default-enable support for Rust.\n Consequently, builds will break by default if Rust is not available on the\n build host. The use of Rust can still be explicitly disabled via build\n flags.\n"},{"id":"541370","messageId":"00b7a590-28db-409c-bfa0-27327e6aefa7@gmail.com","threadId":"65464","inReplyTo":"xmqqa4varhod.fsf_-_@gitster.g","subject":"Re: Re*: [PATCH v2 0/4] Enable Rust by default","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-04-10T15:02:33Z","receivedAt":"2026-04-10T15:02:57Z","isPatch":true,"body":"On 4/10/2026 10:52 AM, Junio C Hamano wrote:\n> Subject: rust: we are way beyond 2.53\n> \n> Earlier we timelined that we'd tune our build procedures to build\n> with Rust by default in Git 2.53, but we are already in prerelease\n> freeze for 2.54 now. Update the BreakingChanges document to delay\n> it until Git 2.55 (slated for the end of June 2026).\n> \n> Noticed-by: brian m. carlson \n> Helped-by: Derrick Stolee \n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/BreakingChanges.adoc | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git c/Documentation/BreakingChanges.adoc w/Documentation/BreakingChanges.adoc\n> index f814450d2f..af59c43f42 100644\n> --- c/Documentation/BreakingChanges.adoc\n> +++ w/Documentation/BreakingChanges.adoc\n> @@ -190,7 +190,7 @@ milestones for the introduction of Rust:\n> 1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and\n> disabled in our Makefile so that the project can sort out the initial\n> infrastructure.\n> -2. In Git 2.53, both build systems will default-enable support for Rust.\n> +2. In Git 2.55, both build systems will default-enable support for Rust.\n> Consequently, builds will break by default if Rust is not available on the\n> build host. The use of Rust can still be explicitly disabled via build\n> flags.\n\nThis patch LGTM and safe to add within the release window.\n\nThanks,\n-Stolee\n\n"},{"id":"541375","messageId":"6eb384e6-7134-4f99-a6b6-e8608ccc9dca@gmail.com","threadId":"65464","inReplyTo":"20260409224434.1861422-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-04-10T15:06:00Z","receivedAt":"2026-04-10T15:06:03Z","isPatch":true,"body":"On 4/9/2026 6:44 PM, brian m. carlson wrote:\n> Our breaking changes document said that we would enable Rust support by\n> default in Git 2.53, while still leaving the ability for it to be\n> disabled. Unfortunately, we forgot to do that and my time machine is\n> broken right now, so this series sets it up for Git 2.54.\nThe discussion about how to handle the 2.54.0/2.55.0 release details\nseems to have concluded, so I went to review the series more carefully.\n\nIf we take Junio's patch instead of this series's patch 1, then patches\n2-4 look good.\n\nI had some initial confusion about patch 4's references to Rust being\n\"optional\" and it helps to know that there is a mechanism to _opt out_\nof Rust builds. So the real conclusion is that we're moving from an\nopt-in system to an opt-out system. This is a nice way to make progress\nrelatively safely.\n\nThanks,\n-Stolee\n\n"},{"id":"541398","messageId":"adlXscAv57Xd7p01@fruit.crustytoothpaste.net","threadId":"65464","inReplyTo":"4efc4133-3726-4b9d-8f06-03c07d48af99@gmail.com","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-10T20:04:01Z","receivedAt":"2026-04-10T20:04:10Z","isPatch":true,"body":"On 2026-04-10 at 13:02:13, Derrick Stolee wrote:\n> I'm glad you're remembering to help us follow through on this promise.\n> \n> However, I'm worried that we shouldn't do this change during the rc\n> window for 2.54.0. Perhaps we could get a small patch that updates the\n> docs to say \"we really mean 2.55.0\" that lands in the 2.54.0 release,\n> and then we merge the requirements for the build in the first batch\n> after the release.\n>\n> This would give us a full release cycle to simmer with the requirement\n> instead of slipping it in for the last rc.\n\nThis was actually sent out just before rc0, but Patrick requested some\nchanges in v1. (I forgot to thread it to the previous version,\nunfortunately.) I would like to have it in 2.54 if we can because I\nsuspect 2.55 will be the last release before 3.0, so that doesn't give\nmuch time for people to update and adjust if there are problems.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"541399","messageId":"xmqqpl46o980.fsf@gitster.g","threadId":"65464","inReplyTo":"adlXscAv57Xd7p01@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-10T20:23:43Z","receivedAt":"2026-04-10T20:23:47Z","isPatch":true,"body":"\"brian m. carlson\" writes:\n\n> On 2026-04-10 at 13:02:13, Derrick Stolee wrote:\n>> I'm glad you're remembering to help us follow through on this promise.\n>> \n>> However, I'm worried that we shouldn't do this change during the rc\n>> window for 2.54.0. Perhaps we could get a small patch that updates the\n>> docs to say \"we really mean 2.55.0\" that lands in the 2.54.0 release,\n>> and then we merge the requirements for the build in the first batch\n>> after the release.\n>>\n>> This would give us a full release cycle to simmer with the requirement\n>> instead of slipping it in for the last rc.\n>\n> This was actually sent out just before rc0, but Patrick requested some\n> changes in v1. (I forgot to thread it to the previous version,\n> unfortunately.) I would like to have it in 2.54 if we can because I\n> suspect 2.55 will be the last release before 3.0, so that doesn't give\n> much time for people to update and adjust if there are problems.\n\nHuh? I actually was hoping that we would tag 2.95 when everybody\nfeels that 3.0 is on the horizon, and if we are lucky jump directly\nto 3.0 (while leaving us room to issue 4 extra 2.XX releases if the\ntimeline turns out to be too aggressve after we got such an\nagreement and 2.95 turns out to be premature).\n\nYou are saying that we'd skip 2.56 and jump directly to 3.0 at the\nend of September? I do not recall seeing any discussion, let alone\na concensus (rough or not) with such a short timeframe.\n\n"},{"id":"541405","messageId":"xmqq4ilio6wp.fsf@gitster.g","threadId":"65464","inReplyTo":"adlXscAv57Xd7p01@fruit.crustytoothpaste.net","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-10T21:13:42Z","receivedAt":"2026-04-10T21:13:45Z","isPatch":true,"body":"\"brian m. carlson\" writes:\n\n> This was actually sent out just before rc0, but Patrick requested some\n> changes in v1. (I forgot to thread it to the previous version,\n> unfortunately.)\n\nProudly saying \"It was sent before rc0\", as if that gave community\nplenty of time to adjust, is not something I was expecting to hear.\n\n\"This is expected to be a big impact change, so I am sending it\nbefore -rc0 of this cycle, so that it can be in the first batch that\ngraduates to 'master' for the next cycle\" would have been a lot more\nunderstandable, though.\n\nThis, and other small things like writev() topic, reminds me what\nI've been wondering for some time about our development process.\n\nWe have been operating this way:\n\n - There are 6 to 8 weeks of period, during which at any time\n anybody can send in any random changes, and as soon as a rough\n consensus is reached that it is a good idea, a topic is merged to\n 'next' and after spending a week there merged down to 'master'.\n\n - There is a \"cut-off\" time at -rc1. After that we go into\n \"regression fix only\" prerelease freeze. We typically do an -rc2\n and the final after that, and this process typically takes 2.5\n weeks.\n\nThis forces topics that are apparently (even though in retrospect it\nonly was superficially) good topic that came late to spend too little\ntime to make the cut-off time.\n\nI wonder if we should do this a bit differently.\n\nWe may want to have a mechanism to sift topics (as they come in)\ninto \"architecturally important high impact\" changes and the rest by\ncommunity concensus. We require that the former be kept in 'next'\nuntil the final release, unless they mature before '-rc0'.\n\nEssentially, '-rc0'would become the new cut-off time for these high\nimpact topics, while '-rc1' will be the cut-off for the rest.\n\nAnd we move '-rc0' way before '-rc1'. Perhaps to week 3 or 4 of the\ncycle, from the current week 6 to 8. Currently \"rc0\" is no more\nthan \"we happen to have accumulated these random topics during this\ncycle and this is a preview\", which is boring, but we can reframe it\nas \"there may be more smaller topics coming, but all architecturally\nimportant high impact changes in the upcoming release are in here\nand no more will be added until the final release.\" preview. If you\nare not in the mainstream (you are on a minority platform, or your\nworkflow is pecurilar, or you depend on some third-party tools on\ntop of Git, etc., etc.), this is the version to test and report\nbreakages in, to make sure that the next release won't hurt you.\n\nWould that improve the process and allow us to experiment with\nlarger changes early in the cycle, with plenty time to correct\ncourse, allowing us scramble less at the last minute during the\nprerelease freeze period?\n\nI dunno.\n"},{"id":"541406","messageId":"adlwGv8LPdfwP8Yv@fruit.crustytoothpaste.net","threadId":"65464","inReplyTo":"xmqq4ilio6wp.fsf@gitster.g","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-10T21:48:10Z","receivedAt":"2026-04-10T21:48:11Z","isPatch":true,"body":"On 2026-04-10 at 21:13:42, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > This was actually sent out just before rc0, but Patrick requested some\n> > changes in v1. (I forgot to thread it to the previous version,\n> > unfortunately.)\n> \n> Proudly saying \"It was sent before rc0\", as if that gave community\n> plenty of time to adjust, is not something I was expecting to hear.\n> \n> \"This is expected to be a big impact change, so I am sending it\n> before -rc0 of this cycle, so that it can be in the first batch that\n> graduates to 'master' for the next cycle\" would have been a lot more\n> understandable, though.\n\nThis change was announced on the list and in the documentation, so its\nappearance should not be a surprise.\n\nI didn't realize that I was sending it directly before -rc0 because I'm\nnot usually very attuned to the timeframe in between releases, to be\nhonest. I usually send patches as my schedule allows and I try to fix\nanything I've broken relatively quickly and even faster in the -rc\nperiod, and I generally let you decide how and when to merge them.\n\nIn this particular case, I merely remembered that it was something we\ncommitted to because I actually was looking at the BreakingChanges\ndocument for other reasons, so I sent a patch as soon as possible. That\njust happened to be right before -rc0. Had I remembered earlier, I\nwould of course have sent the patch earlier. It appears, however, that\nwe all had a memory lapse in this case and I do apologize for my part in\nthat.\n\nI don't have a strong opinion here and if you prefer, we can defer to\n2.55. I agree that would be less risky at this point in the release\ncycle and, of course, you are the maintainer.\n\nI have been operating under the assumption that Git 3.0 is destined for\nSeptember 2026 based on the discussions we had at the September 2024\nContributors' Summit in Berlin where we said 1–2 years, as well as other\ndiscussions on the list, and that is the message I have been\ncommunicating to other people and projects[0]. I am fully aware that\nthat date might slip due to various reasons[1], but I do very much want\nto get as many things set up as possible so people can test and there\nwill be fewer surprises, which was of course the reason for sending in\nthis series. I imagine, for instance, that Debian might ship a\nWITH_BREAKING_CHANGES version in experimental for testing to find all\nthe exciting things that will break (of which I am aware of quite a\nfew). (I will suggest that to them shortly.)\n\n[0] This is true in both my personal and professional roles.\n[1] Although I am unable to be more specific, let us just say that I am\nendeavouring to do everything I can such that the date does not slip for\nany reasons within my control.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"541408","messageId":"adl7JnCX5ndoAQNt@fruit.crustytoothpaste.net","threadId":"65464","inReplyTo":"xmqqpl46o980.fsf@gitster.g","subject":"Re: [PATCH v2 0/4] Enable Rust by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-10T22:35:18Z","receivedAt":"2026-04-10T22:35:19Z","isPatch":true,"body":"> Huh? I actually was hoping that we would tag 2.95 when everybody\n> feels that 3.0 is on the horizon, and if we are lucky jump directly\n> to 3.0 (while leaving us room to issue 4 extra 2.XX releases if the\n> timeline turns out to be too aggressve after we got such an\n> agreement and 2.95 turns out to be premature).\n> \n> You are saying that we'd skip 2.56 and jump directly to 3.0 at the\n> end of September? I do not recall seeing any discussion, let alone\n> a concensus (rough or not) with such a short timeframe.\n\nWhat I recall having seen suggested on the list is that we were thinking\none of the 2.5x releases would be the last release before 3.0 (I think\nmaybe somewhere in the Rust discussion), but I don't think we actually\ndiscussed it in any detail. We did definitely discuss the 1–2 year\ntimeframe at the September 2024 Berlin Contributor Summit, though, which\nhas been my guide for getting things ready for Git 3.0.\n\nI think your proposal here sounds more sensible, though, and possibly\nnicer for downstreams since 2.95 reads more like \"getting ready for 3.0\"\nthan 2.55.\n\nAnyway, we should probably start a separate thread to discuss plans for\nthe 3.0 release and what we think is missing for that. That would be\nmore discoverable than hiding it here.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}