On Thu, Sep 04, 2025 at 01:38:52PM -0400, Eric Sunshine wrote:
> On Thu, Sep 4, 2025 at 10:30 AM Patrick Steinhardt <ps@xxxxxx> wrote:
> > Over the last couple of years the appetite for bringin Rust into the
> > codebase has grown significantly across the developer base. Introducing
> > Rust is a major change though and has ramifications for the whole
> > ecosystem:
>
> s/bringin/bringing/
>
> > Instead, preceding commits have introduced a test balloon into our build
> > infrastructure that convert one tiny subsystem to use Rust. For now,
> > using Rust to build that subsystem is entirely optional -- if no Rust
> > support is available, we continue to use the C implementation. This test
> > balloon has the intention to give distributions time and let them ease
> > into our adoption of Rust.
>
> If it's entirely optional and automatically disabled on platforms
> which don't have Rust installed/available, then it isn't a test
> balloon, is it? All previous test balloons in this project were
> architected in such a way that Git would fail to build if the platform
> in question lacked the feature being "test-ballooned", and the idea
> was that packagers of those systems would alert the Git project about
> the problem or somehow resolve it themselves via the platform's local
> build infrastructure.
>
> However, with the approach implemented here, Git will build as usual
> on all platforms on which it already builds successfully, which means
> that the Git project is unlikely to hear complaints from packagers,
> especially if packagers haven't followed the relevant discussion
> threads and are unaware that a Rust test is being conducted. Moreover,
> the project has already heard from some packagers/maintainers that
> Rust support is lacking or (currently) impossible, so the project
> already has the sort of knowledge that a test balloon is intended to
> elicit.
>
> That's not to say that the changes implemented by this series can't be
> valuable, but rather that for these patches to be valuable, you
> probably need some way to advertise the test more loudly so that
> packagers actually attempt the Rust build. One possible way to rectify
> this shortcoming would be to enable the Rust code by default in the
> Git project but give packagers a way to opt out of it if they can't
> make it work on their platforms.
Very true indeed. Thinking about this, how about we make this a
multi-step process?
1. Introduce the feature as "auto"-detected on Meson and disabled in
our Makefile. This allows us to get comfortable with the tooling
and address any issues we find iteratively.
2. Change Meson to default to "-Drust=enabled" and change our Makefile
to make Rust opt-out instead of opt-in. Distros can still disable
this, but should now be alert that something is upcoming.
3. Remove the feature toggles altogether. Rust is now mandatory.
If this patch series here lands (1) would be the status quo. In one or
two releases we could then do (2). And with Git 3.0 we can finally do
(3).
I'll add this process to the BreakingChanges document to give readers
some guidance.
Patrick
