On Thu, Jul 11, 2024 at 1:12 PM Kyle Lippincott <spectral@xxxxxxxxxx> wrote: > > On Thu, Jul 11, 2024 at 11:15 AM Emily Shaffer <nasamuffin@xxxxxxxxxx> 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" Yeah, I agree that I'm somewhat uninterested in enumerating a set of deps/criteria that will then magically assure it works - that does sound like a hassle to keep up-to-date, and in fact I think would set us backwards from the goal of this doc. We'd feel tied to that criteria without any ability to move forward, which would probably be our current status quo or worse. So, I'll make it clear to reflect the second thing you're saying in the reroll. - Emily
