<rsbecker@xxxxxxxxxxxxx> writes: > I think we might want to add some considerations to the above list > that go beyond what other projects use, OpenSSL as an example: [jc: if you want to have a meaningful discussion on this list, please stick to a reasonable line width. I'll rewrap your lines below]. > * Can support for exotic platforms be delegated to some > "community" support concept. In NonStop's case, I currently do 99% > of the verification that each release runs properly. If I am able > to provide a fix, I will. We have been fortunate that most > problems/solutions have been of general interest and impact, with > my platforms being more of a "Canary in the Coalmine" situation > where we just encounter it first because of edge conditions, but > other platforms may be impacted. The problem here is time of how > long a designated community support person(s) can keep supporting > git and what happens when they (me) retire or get hit by a > bus. Like all good NonStop people, I have a backup, so git does > not need to worry about me specifically. There are platform packagers that deliver binary releases, and we do not have to worry about them. We _could_ have a tier of minority platform that we can treat pretty much the same as these packagers, i.e. the "community supported version of Git for platform X" might consist of many patches on top of what I release, and some patches that are acceptable quality may be given upstream, but there may need hacks that are too ugly to live in my tree, which the "community edition" may have to keep outside the upstream. Even in such a case, if they try to engage with this list, they will often find somebody willing to help them polish such "ugly hacks" into acceptable patches. > * What is the broad impact of dropping support for a platform that > has a significant investment in git, where loss of support could > have societal impact. There are platforms with 100 million to 1000 > million lines of code managed by git today. This type of > investment-related impact is specific to git compared to other > Open-Source products. Leaving debit or credit card authorizers > without a supported git would be, let's say, "bad". Let's say we may want to start requiring new enough version of library that is not yet ported to a minority platform. Do we deeply care? It depends but "investment-related impact" is unlikely cause for us to personally care. But those $CORPS who will feel the "investment-related impact" are welcome to hire quality developers and to these employed developers, the "impact" might become an issue they care more deeply about. > * Could stakeholders be consulted before changing support levels? > Yes, I get that commercial fee-based products hit this more than > Open-Source. Looking at other products in the Open-Source space, > there are fee-based support models that could be developed for > long-term support (beyond the obvious LTS-type considerations - > see OpenSSL's model for reference). The stakeholders are already consulted, aren't they? Every time we make noises like "let's raise the minimum version of Perl we require", we discuss it here. They have to monitor this list, of course, and if they lack people to do so, then they may have to invest in it. > A related question is: "If there is a bug detected in git, what > version is the oldest supported git version to which a fix can be > made?" This is a good question. The latest security-induced maintenance release was Git 2.40.1 done in March 2023 and the fixes go back to the v2.30 track, and Git 2.30.0 was done at the end of 2021. This window was unusually generous from our usual standard, IIRC, so I would say roughly speaking 2 years is the maximum. > ... But this position puts pressure on the team to maintain > platform compatibility for indefinite periods. Sure, but I think we should just say something like "18 months to 24 months", if you want backport of a fix to older track, you can do so yourself. The story is probably the same if a minority platform that lacks recent enough dependencies (e.g. libraries) and stop linking correctly. If you care deeply enough, you should be ready to invest yourself in porting such dependencies. We can help, but the primary driving force for porting issues ought to be folks with stake in the platform. We as the project won't bend over backwards and keep everybody else to an ancient version of the dependency if some platforms cannot catch up with the time.
