Re: [PATCH] Documentation: add platform support policy

>
> On Thu, Jul 11, 2024 at 11:15 AM Emily Shaffer <nasamuffin@google.com> wrote:
> >
> > On Tue, Jul 9, 2024 at 4:16 PM brian m. carlson
> > > I think it's also worth discussing what we require from a platform we're
> > > willing to support.  For example, we might require that the platform
> > > pass the entire testsuite (ignoring irrelevant tests or tests for things
> > > that platform doesn't use, such as Perl) or be actively pursuing an
> > > attempt to do so.  We may also want to require that an OS be actively
> > > receiving security support so that we don't have people asking us to
> > > carry patches for actively obsolete OSes, such as CentOS 6.  Finally,
> > > some sort of time limit may be helpful, since some Linux vendors are now
> > > offering 15 years of support, and we really may not want to target
> > > really ancient versions of things like libcurl.
> >
> > I sort of wonder how much of this is taken care of by expressing
> > "fully supported" as "can run in GitHub Actions". Even if an LTS
> > distro is 12 years old and using ancient curl, will GitHub still be
> > able to run it in a VM/container? Maybe there's no such guarantee,
> > since you can hook up self-hosted runners (which sounds more appealing
> > if someone's got something weird enough it doesn't run well in a
> > container).
> >
> > I'm not sure which of these requirements we'd want to enumerate - but
> > does it make sense to tack it onto the end of this doc? Something
> > like:
> >
> > """
> > Minimum Requirements
> > ------
> >
> > Even if tests or CI runners are added to guarantee support, supported
> > platforms must:
> >
> > * Be compatible with C99
> > * Use curl vX.Y.Z or later
> > * Use zlib vA.B.C or later
> > ...
> > """
>
> My concern with actually listing what the minimum requirements are is
> that we then need a process for raising the minimum requirements. For
> C specification, I can see that rightfully being an involved
> conversation and achieving consensus that this is the right time to do
> it. For things like library versions, I'm less comfortable with it
> because if we have to raise the minimum bar for some urgent reason,
> there's the potential for additional friction with these platforms
> claiming that we stated we'd support them (ex: we say you need to be
> able to use libfoo v3.x.x (v4.x.x had some breaking changes, but
> coexists with v3, so we just stuck with v3), and some security fix
> that we need to receive only exists on the v4 version, so now we need
> to port to using v4 so that we get the security fix).
>
> I think it's probably fine to list minimum requirements, as long as we
> have something conveying "and possibly other criteria". I don't want
> this interpreted as a "do this, and we will try hard to not break
> you", it should be interpreted as "if you can't do at least this, we
> won't even look at patches/tests/CI to unbreak you/keep you unbroken"