Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

From: Elijah Newren <newren@gmail.com>
Date: Sep 9, 2025, 06:33 UTC
Message-ID: <CABPp-BEW8TYaffOED34bTy98X=CDZeA+r=X+kMR-GRwuqRDfjg@mail.gmail.com>
In-Reply-To: <aL57ONmEKTmqFhIZ@pks.im>

On Sun, Sep 7, 2025 at 11:44 PM Patrick Steinhardt <ps@pks.im> wrote:

>
> On Sat, Sep 06, 2025 at 09:31:02PM -0700, Elijah Newren wrote:
> > On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@pks.im> wrote:

[...]

Show 25 quoted lines

> > > I have a plan layed out in the BreakingChanges document that mentions
> > > how I'm proposing to do the transition:
> > >
> > >   1. We introduce it with auto-detection for Meson and default-disabled
> > >      for our Makefile in Git 2.52.
> > >
> > >   2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
> > >      in Git 2.53.
> > >
> > >   3. We always enable Rust by default in Git 2.54.
> >
> > I don't see how steps 1 & 2 help at all.  We now know we want to make
> > Rust mandatory eventually, and should provide distributors and
> > platforms as much notice as possible so they are aware.  But what
> > you've proposed is another libgit-rs or libgit-sys -- an optional
> > component that no one will know about unless they go looking for it.
> > I don't see how those two steps provide any incremental help to
> > anybody over what libgit-rs and libgit-sys have done.  From my point
> > of view, Rust should be enabled by default in Git 2.52, with a simple
> > knob provided to let distributors/platforms/users turn it off and
> > build without it.
>
> It helps because it allows us to slowly build out the infrastructure. We
> don't yet need answers to every question that we currently have if we
> initially have the Rust infra default-disabled.

One of the things I find very unfortunate about this series, is we have a new contributor who was trying to send in patches, and instead of providing feedback, suggesting alternatives, or asking if he'd do it differently (which he actually said he was willing to do [1]), it sends out a competing patch series to replace his instead. (And this happened shortly after someone else interjected patches because of interest in the first area he touched, forcing him to pivot once already[2].) Further, despite him having solved how to get it running on all platforms we run in CI with some big help from the git-for-windows folks, this series discards all of that. It lends to a feeling that he might be working on important and interesting topics, but his changes aren't welcome and it's not worth providing feedback for him to modify them to become so. That's almost certainly not your intent, but that is the effect that sending a competing patch series likely is going to have.

[1] https://lore.kernel.org/git/CAH=ZcbBLAKaE733_2_2qbFTYCfwGq37RfF-Z3vaKL1ZR49msAA@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqzfbvfxs6.fsf@gitster.g/

> I very much expect that there'll be some issues with our initial first
> steps. So I'd rather want to avoid to expose developers or distros to
> these issues directly, because that might train them to immediately
> disable Rust right from the start.

I don't understand why that matters. The whole point you gave to motivate this series was to make distributors aware that mandatory Rust is coming. If they disable it early on, that requires them to have been made aware, so mission achieved. Making it optional and off-by-default means they get no notice until multiple releases down the road until you do turn it on, shortening the window they have to be alerted and prepared. To me, this feels like you're snatching defeat from the jaws of victory.