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

> 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.

> > +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".