Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> +* Git will require Rust as a mandatory part of the build process. While Git
> +  already started to adopt Rust in Git 2.52, all parts written in Rust are
> +  optional for the time being. This includes:
> ++
> +  ** Subsystems that have an alternative implementation in Rust to test
> +     interoperability between our C and Rust codebase.
> +  ** Newly written features that are not mission critical for a fully functional
> +     Git client.

This is a bit funny way to phrase the intent, even though I do fully
support the intent expressed here.

When this topic becomes part of the code base, we are likely to have
varint in the first category, but if we have nothing that falls in
the second category, that would feel somewhat odd.

> +These changes are meant as test balloons to allow distributors of Git to prepare
> +for Rust becoming a mandatory part of the build process. There will be multiple

Are they still "test balloons"?  I thought that we established that
the point of these breaking changes is quite different from what we
have called "test balloons" for.  It is not like allowing them
anything (like interfering to delay or stop, which would not likely
to happen at this point if this patch gets part of the code base),
but is used as a bit more forceful way for us to tell them and make
sure they are aware of the upcoming change.

> +milestones for the introduction of Rust:
> ++
> +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
> +   disabled in our Makefile so that the project can sort out the initial
> +   infrastructure.
> +2. In Git 2.53, both build systems will default-enable support for Rust.
> +   Consequently, builds will break by default if Rust is not available on the
> +   build host. The use of Rust can still be explicitly disabled via build
> +   flags.
> +3. In Git 3.0, the build options will be removed and support for Rust is
> +   mandatory.

I like the vagueness of the gap between step 2 and 3 here ;-)

> +The Git project will declare the last version before Git 3.0 to be a long-term
> +support release. This long-term release will receive important bug fixes for at
> +least four release cycles and security fixes for six release cycles. The Git
> +project will hand over maintainership of the long-term release to distributors
> +in case they need to extend the life of that long-term release even further. In
> +that case, the backporting process will be handled by these distributors, but
> +the backported patches will be reviewed on the mailing list and pulled in by the
> +Git maintainer.

I am having a hard time imagining the practicality of this "hand
over but we still review" arrangement.  Some of the security fixes
are embargoed, and the reason why we are jetissoning the stale
codebase is presumably because nobody is willing to work on it other
than the "community support" folks.  I can imagine that we would
qualify them into the git-security cabal and let them use the forum
to coordinate among themselves, but then to what degree in the
"community support themselves" process is our involvement expected?
As long as we can make sure that they do not leak before the
official embargoed release, they do not need an official stamp of
approval from the project or by the Git maintainer---that is what it
means to "hand over maintainer ship", at least to me.

In other words, I like what I see in this paragraph, but I do not
think we can practically live with the part of the sentence after
the last ", but".

Thanks.