From: Phillip Wood Date: Mon, 08 Sep 2025 10:12:20 GMT Subject: Re: [PATCH v3 02/15] xdiff: introduce rust Message-ID: In-Reply-To: <042f01dc2011$da9dcda0$8fd968e0$@nexbridge.com> Hi Randall On 07/09/2025 17:09, rsbecker@nexbridge.com wrote: > On September 7, 2025 12:10 AM, Elijah Newren wrote: >> Sorry for the delay; life outside of work is challenging at the moment... >> > > I am going to address the critical point mentioned below and snip the rest for brevity. > >> I still don't see why distributors _must_ ship the latest version of Git and why folks >> on some platforms are considered broken if they are using a slightly older version. >> Let me ask again: has anyone answered why this is considered mandatory? If they >> have, I've missed it, but I've asked multiple times. Even if you want to lump >> "distributors cannot build a newer version" under the umbrella of "breaking >> changes", I argue it's a much different kind of break and one which merits different >> timelines for handling than e.g. lumping it in with 3.0. > > I do not see that distributors _must_ ship the latest version. Suppose we are on > 2.51.0 and a CVE comes out that prohibits its use in an organization that does > not allow any medium-high to high CVEs. This represents hundreds of thousands > of impacted users in my community alone. How does the CVE get applied if the > latest cannot be built and the git team does not apply the CVE fixes to old > versions. Personally, I do not care if git versions are different between work > and home, or even between CI/CD and other platforms. I don't even care > if I have to use JGit instead of git in some situations (which I see is a likely > outcome of this discussion). Is there an official statement of what an LTS > means? We're currently discussing what promises we can make about supporting a non-rust version of git. > In other projects LTS is typically, and formally by policy 5 years. I know commercial linux distributions offer that kind of support but are there really open source projects that guarantee 5 years of security updates without any kind of support contract? > From what others have said here, positions of 6 months, 3 years, and > "apply it yourself if you want to continue to use git" have been made. Yes it is still being discussed, and no one is volunteering to offer five years of support. > The core problem of adding a breaking dependency is when a CVE comes > out that prohibits git from being used at all. If the git team is not going > to provide a clear statement, one way or another, if how CVEs (at > whatever severity level) will not have a commitment of any kind, > then distributors are essentially cast adrift and on our own. It would > be helpful of those of us who donate our time, for no compensation, > are able to plan for this in a meaningful way. Doesn't your company make a front end to git? Are you saying that the management does not allocate any staff time to work on git itself and expects the community to provide it with free security updates? > Please remember that > we have to justify our participation to our management teams to be > allowed to continue to participate. I'm confused by this, as the sentence before say's you're donating your time for no compensation. > Nothing is free from this end > and if fixing (not just applying fixes) CVEs are now 100% our > responsibility, if would be critical to know that when we build our > business cases to our bosses, who I am fairly certain will say an > emphatic no. In the long term, unless your platform gains a rust compiler I'm afraid I think that is most likely outcome. > Also remember that without support from the git team, the > code base is no longer the same, meaning the auditors will not > necessarily accept fixes from third-party sources. I think I saw a suggestion/question about the possibility of hosting any long term support branch that is maintained by interested parties within the main repository. Would that help? I appreciate that any move to rust would be very disappointing and disruptive to you but the community has to weigh up the benefits rust has to offer against that. Phillip > This particular > point enabled adoption on some platforms, particularly NonStop. > Adoption was at 1-2 customers when we had a divergent code > based because some platform fixes being different from the > standard code-base and could not be certified as valid. Once the > code-base because common, adoption was rapid and enthusiastic. > If this goes away, I suspect that adoption rates will go negative. > I am aware that that particular discussion is actually happening > in some organizations in my community right now, with companies > looking for alternatives to git based on this discussion thread. > > With over a decade of respect and participation, > Randall >