Oh, interesting. Are you asking whether we require that PR testing is required to merge? Or whether we just need it to trigger?
My thinking is that a newly promoted Tier 1 platform is likely to want its PR testing to trigger, but we shouldn't block merging on it until we're sure it's reliable. I'm not sure whether that decision would be a matter for the Platform Steering Group or not; given the potential impact, maybe Core Team should make the final decision on moving PR testing to a state that blocks merging?
In some offline discussion today a question around tier 1 for toolchain hosts w.r.t. the DocC Swift PM plugin and Swiftly came up. Right now neither of the two are called out as required. The reason why those two are interesting is because they both depend on multiple packages including Swift NIO. Was there some discussion around those two components?
There was not, although I note that neither DocC nor Swiftly currently work on Windows as far as I'm aware? The list of requirements was intentionally kept to a minimum, but as I've said a few times above, it's the minimum expectation as well as being a minimal list. The Platform Steering Group is likely to ask platform owners who only provide the things in that list why various other components are absent, but the exact list would depend on the platform. That is, the actual expectation for any given platform is likely to be higher, but would be a matter for discussion between the platform owner and Platform Steering Group.
That’s exactly where the question came from. While I think that it’s reasonable to keep the list to a minimum, having the de facto documentation generation plugin or the toolchain installer not working is impacting the developer experience on such a platform quite heavily. We should at least find a place where we call out such limitations to be able to reference it.
NIO's port likewise stalled when it was originally brought up in 2020 (where I even was able to demonstrate it working).
The problem here is that new components (like NIO and DocC) can often be introduced without an included port, but that should not be on the platform owners to port, but rather the responsibility of the project.
I agree that this is not the platform owners responsibility but the platform support level document is not about defining who is responsible for it but rather the different tiers of a platform. I think any Tier 1 toolchain host should be expected to provide all the additional components that developers expect including DocC unless there are target specific reasons why a component can't be included. At a minimum we should at least make it clearly visible what components are available similar to Rustup packages availability on x86_64-unknown-linux-gnu.
Having said that I fully understand the Windows situation and why DocC or Swiftly are not available currently. I just think it is important that it is documented somewhere.
I agree it should be the projects responsibility to not introduce new dependencies that break existing platform support but it is the larger Swift project responsibility to ensure every project has the appropriate CI checks to avoid such accidental breaks.
I think aspirationally, that is true. Practically, we cannot do that unless we can say that no new projects can be introduced without a complete port on all platforms. This becomes even more interesting when you start considering more platform specific nuances (e.g. Windows currently cannot practically ship with SPM produced products as the linkage model in SPM is not fleshed out sufficiently yet).
Of course the PSG would ask why something we expect to be packaged is not, but I don't think that an explicit list makes sense - it is not a carve out for oh platforms routinely do not include something: the broad strokes are aspirational even though practically we might find that we need to make exceptions.
I touched on this briefly here; I don't think we have a formal definition of what components must be or is defined to be included in a toolchain, and doing that would induce defining what packages should comprise a Swift toolchain on a target system.
That being said, I don't think this proposal should deal with this, because it drags in some ancillary concerns that may not apply generally here, but answering that question probably deserves a proposal in and of itself.