Re: [PATCH v3] Documentation: add platform support policy

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

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

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