On Fri, Mar 11, 2022 at 8:43 AM Zachary Ware <z...@python.org> wrote:
> On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg <m...@egenix.com> wrote: > > If there are people in the community who wish to provide support for > > these platforms, I don't see a reason not to keep them in a tier 4. > > Such platforms would not be supported by the core team and don't > > necessarily need a buildbot (even though it would be good to have them). > > > > I find it problematic that the way Brett has written the proposal > essentially > > means that we will not accept any PRs to help support platforms which > > are not listed in the tables. Could be that I misinterpreted his writeup, > > though. > > > > Esp. Android and possibly iOS are platforms which Python should be > > targeting in the future, since the story for Python on those platforms > > currently is pretty. We shouldn't make it harder to eventually gain > > such support and hopefully find new core devs who can maintain them > > to become fully supported. > > As I understand it, the idea here is that if there is no core dev for > a platform, it's not actually supported in a practical sense > regardless of our official policy or lack thereof. The policy Brett > is proposing just makes that explicit and gives us something to point > to when someone comes up with a patch to support PDP-11 or when > someone's patch for Android breaks Windows. I don't think we'll wind > up with tier support police; if a core dev wants to take > responsibility for a patch for a platform that is not tier 3 or above > they can still do that, but if it breaks things for a supported > platform it will be reverted. > > If there is serious support for a non-tiered platform, all it takes is > a buildbot and either an existing core dev to sign up to be the > maintainer or for us to vote in a maintainer, and then it can be a > tier 3 platform. If there's not someone actively maintaining it and > the tests regularly being run on it, we can't realistically claim to > support it anyway. > > I don't see much value in a tier 4: all other platforms that aren't > tier 3 or above are tier 4. We could link to a wiki page for where > one might find links to support communities for non-tiered platforms, > but I expect such a list would bitrot at a rate that makes it not > worth including in the official tier list, whether by those > communities fading away or the platform being promoted to tier 3. > > > On Thu, Mar 10, 2022 at 5:36 PM Brett Cannon <br...@python.org> wrote: > > Tier 1 > > ====== > > > > - `Test suite failures < > https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ > block releases. > > - Changes which would break the ``main`` branch are not allowed to be > merged; > > any breakage may be reverted immediately. > > - All core developers are responsible to keep these platforms working. > > - Promotion of this tier requires consensus/SC approval. > > Should tier 1 require pre-merge CI? We can currently do that, but > promoting a platform that's not provided by GHA could require > significant workflow changes. > That was meant to be implied by the "you can't break `main`" line, but I'm happy to make that explicit. > > > - Must have a stable buildbot. > > I have concerns about the term "stable buildbot". Until now, the > "stable"/"unstable" tags on buildbots have been the closest thing > we've had to a platform support policy and we've treated failures on a > "stable" buildbot to be release blockers (for the most part). With a > proper platform support policy, "stable"/"unstable" should become a > description of the reliability of the particular worker machine to > provide an accurate representation of the state of the tests on the > platform rather than whether the tests usually pass, but I'm worried > about confusion from the changing meaning of those labels. > I'm somewhat using the term as a bridging mechanism. I'm assuming if this change goes in that the buildbots representing these platforms will get appropriate labels and that's really what's going to be representative of a "stable buildbot". I'm also happy to change the wording to "reliable".
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/AFSLV6F3JNRZAHOYKSFYKZQFCIZK7YCA/ Code of Conduct: https://www.python.org/psf/codeofconduct/
