On Thursday, July 25, 2024 2:53 PM, Emily Shaffer wrote:

On Thu, Jul 18, 2024 at 3:46 PM Junio C Hamano [off-list ref] wrote:

[..snipped nits, I have fixed them for v4]

quoted

quoted

+* You should run nightly tests against the `next` branch and
+publish breakage
+  reports to the mailing list immediately when they happen.

Can't it be daily instead of nightly ;-), or is it better than nothing
if you can afford to run only once every other day?

A topic (unless it is during the shuffle time around -rc0) usually
spends no less than 7 calendar days in 'next', so while I would
appreciate if somebody runs tests twice a day, in practice you should
be able to catch a new breakage in 'next' if you run a full and
thorough test twice a week.

I ended up adding a sub-point to explain cadence preference and reasoning, since
that's a lot to fit into a parenthetical. Thanks.

quoted

quoted

+* You should either:
+
+** Provide VM access on-demand to a trusted developer working to fix the

issue,

quoted

quoted

+   so they can test their fix, OR

"VM access on-demand" -> "on-demand access to your platform" (iow,
physical iron is also fine for our purpose).

Done, thanks.

quoted

quoted

+Minimum Requirements
+--------------------
+
+Even if platform maintainers are willing to add tests or CI
+runners, we will not consider helping to support platforms that do
+not meet these minimum
+requirements:
+
+* Has C99 or C11

OK.

quoted

+* Has dependencies which were released in the past 10 years

This is hard to understand and I wonder if we can clarify.  I get what
you want to say: suppose we rely on library X that is getting regular
feature and security updates in reasonable cadence, say every 6 months
there is an upstream release of library X, but a niche platform has
ported the library only once long time ago, and hasn't updated it ever
since.  Now the Git project may consider helping a port to such a
platform if the initial port of library X was 8 years ago, but will
not if it was 12 years ago.

But if Git depends on an ultra stable library whose last public
release was 12 years ago, disqualify everybody is not what this
requirement wants to do.

I attempted to formulate my version along ...

    Keep up with the versions of dependencies (libraries, etc.) and
    not to lag behind compared to typical mainstream platforms by
    more than X years.

... the above line, but to me it is no better than the original, so I
failed miserably.  But the idea I am bringing to the table here is
that time of release is not absolute.  If typical mainstream platforms
consider a release of a library made 8 years ago from the upstream
performant, functional, and secure enough and fit for use, we do not
consider that they are approaching the limit.  But if another platform
uses the same library from 12 years ago, i.e.
lagging behind others by 4 years is a problem at the same graveness
using another library that was released 6 years ago, when other
platforms are using a much younger vintage of the same library
released at 2 years ago.

Yeah, I think it makes sense to relax just a little bit more, and give ourselves flexibility
to use common sense. I ended up with:

"""
* Uses versions of dependencies which are generally accepted as stable and
 supportable, e.g., in line with the version used by other long-term-support
 distributions
"""

It's not quite my favorite, still, because I guess that LTS distros could get to a point
we don't want to support (do we really want to provide cutting-edge git features to
a 25-year-old LTS distro, for example?). Plus, "just look at everyone else's
homework and use that"
feels a little weird.

A common practice across many commercial and Open Source projects is to fix LTS at a 5 year limit and usually for
High-CVE class security fixes. That is, at least, when there is a commitment to retroactively fix problems. The
Impression (from the outside of git - until about a year ago when "friends" fixes where done) is that the way to get
a git fix is to upgrade. Somewhere in the middle would be more appropriate, I think. I do not think 25 year LTS
is common, useful, or even likely, even for exotics (we use 5 year since a fixed announcement of a "closed selling
date"). We could designate 2.46 as LTS 5 years from next week, as an example, which might not be so terrible. But
LTS tends to be for qualified fixes only, like CVEs at a certain level, with functional stability (no enhancements
allowed after a specific date - say "official release + 1 year"). OpenSSL is a bit more stringent, where once an LTS
designated release moves past beta, there are no functional changes allowed, just bug fixes, and about a year later,
just security fixes. When establishing an LTS, my core requirement is that I have a compatible supported
compiler, not just a compiler available. For example, the minimum OS I support is 7 years old - 2 during active
sales + 5 years after, which aligns with the vendor's OS policy. This also means that I might use c99, but only a
fully supported c99+toolchain, not just one that is available that might run on the box. This means that any
shipped binaries are not guaranteed to run on any OS version that is no longer supported, including the
compilers on that version - probably more rigid than git would need though. May 2024 was a big month
because a bunch of things were deprecated/dropped. This type of policy does take active product
management, which, in gits case, would need volunteers who actively watch conditions on relevant platforms - I
do that for the git builds on NonStop, so my team stops building git versions for dropped OS releases.
My only issue there is cleaning up "dead" versions so people cannot download git builds that we are pretty
sure will no longer run (there are complex reasons it is a difficult activity).

... but I have gone on too long, but LTS is a very heavy-weighted term with generally stringent rules. The above
was really just context for decision-making around LTS, not specific comments about the content. Sorry.

Will keep thinking on this, I'd welcome other suggestions for phrasing.

quoted

Having said all that, everything I removed from my quote I found
agreeable.  Very well written.