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

+* 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

+* You should either:
+
+** Provide VM access on-demand to a trusted developer working to fix the issue,
+   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

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

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

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

Thanks. :)

 - Emily