Subject: Re: Defining a platform support policy

From: Junio C Hamano <[email-masked]>
Date: Mon, 22 Jan 2024 16:57:47 -0800

<[email-masked]> 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.