Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

[Patrick Steinhardt <ps@pks.im>]

On Sun, Sep 07, 2025 at 09:39:08PM -0700, Junio C Hamano wrote:
> This is a tangent, but as many people pointed out, calling this a
> test balloon is misreading.  This is quite different from what we
> traditionally called a test balloon, where 
> 
>  - we were already fairly sure that the construct is safe, but
>    wanted to be extra careful to smoke out anybody who has trouble
>    with it;
> 
>  - hence we use the construct in question in a place where nobody
>    can compile it out, hoping that anybody with a system incapable
>    of handling the construct in question would be broken badly,
>    reporting the breakage to us;
> 
>  - this is done with an understanding that even a single "the
>    compiler on this this platform with more than dozen thousands
>    users cannot groke it" would automatically stop us, causing us to
>    revert that test balloon code for _everybody_, refraining from
>    using that construct for _everybody_ until the situation changes.
> 
> This thing is different at all points.  We are not "fairlu sure that
> Rust is safe to use for everybody"  Far from it.  We are confident
> that requiring Rust would break known people.  We are doing this not
> because we intend to stop once we know of folks who would be broken.
> Far from it.

That's fair. I still think that this conversion is viable though. The
main intent here is to start building the infrastructure for Rust, which
may take a bit of iteration to fully get there. And the earlier we start
with the process the better, so I think we should go ahead with this
regardless.

From that perspective it still feels like a test balloon to me. The
intent here is less to figure out whether anything breaks. It's more
that we need to have some Rust code in central parts of Git to be able
to tell whether our Rust infra works in the first place. And it allows
downstream packagers to give it a try, as well, so that they can start
to report any issues with our infra before it becomes mandatory.

I don't mind much whether we want to call it a "test balloon" or not.
But giving it a name helps, and "test balloon" is the closest match and
I don't really have a better name. If somebody else does I'm happy to
adapt the wording though.

> It would really be nice to find a niche that can be a new optional
> feature that is not essential to the functioning of the system
> implemented in an already modularized part of the system (e.g., an
> optional merge strategy, diff algorithm, built-in textconv filter, a
> new ref backend, etc.).  Then we can introduce Rust, knowing that
> some Rust-challenged systems will not be able to use these optional
> features.  What Brian mentioned about two-hash interop feature,
> being only available on Rust-capable systems, could be such an
> optional feature, and if it can be done that way, that would be very
> welcome.  If we can have Rust goodness soon enough without making it
> mandatory in too short a timeframe, that would be ideal.

I feel like this is something we should _also_ do. But for now I'd like
to continue with "varint.rs": it's easy to convert, self-contained and
allows us to iterate on our tooling while we don't have a better
subsystem or feature to convert yet.

> I already said that I find 6 months advance notice to folks on
> Rust-challenged systems is way too short to be any good.  If the
> only reason we give advance notice is because we want to make an
> excuse of cutting them off sooner while being able to say that we
> gave them advance notice, that may be sufficient.  But if we truly
> want to help them by giving enough time to them so that they can
> help their platform themselves, by lobbying, fundraising, or
> otherwise campaigning to have usable Rust on their system, I really
> do not think it is sufficient.

Yeah, agreed, six months feels insufficient. My current timeline
suggests roughly a year before we make it mandatory with 3.0 with
various in-between steps that gradually ease into Rust to alert
packagers. Which still may not be sufficient, but it should hopefully
okayish if we also commit to 1.5 years of security fixes.

In any case, the exact timeline very much is an open discussion point.

Patrick