[python-committers] Re: Consider adding a Tier 3 to tiered platform support
On Thu, Mar 31, 2022 at 4:40 PM Victor Stinner wrote: > Hi, > > I don't think that the current PEP 11 draft (*) describes correctly > the current status of a bunch of platforms which are not "actively" > supported. I like to call these plaforms as "best effort support" > platforms. I propose considering adding an explicit "Tier 3" to PEP > 11. > > (*) https://github.com/python/peps/pull/2442/ > > Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust > codebase has support for, but which the Rust project does not build or > test automatically, so they may or may not work." > > Tier 3 requirements would be *very weak*: > > * No buildbot requirement > * No assigned core dev needed > * Don't revert a change breaking a Tier 3 platform > * Don't hold a Python release if a Tier 3 platform is broken > > Currently, the "All other platforms" section is quite clear: code can > be removed anytime: > > "Code changes to platforms not listed in the above tiers may rejected > or removed from the code base *without a deprecation process* if they > cause a maintenance burden or obstruct general improvements." > > The only difference between "Tier 3" and "All other platforms" would > be that removing a platform from Tier 3 require a process. I'm not > sure if a deprecation is needed. But we have to go through a > discussion and someone (SC?) has to decide if it's ok to drop it > (remove code). > If there's no buildbot making sure the platform works and no core dev trying to keep it working, then what's the point of listing the platform in the PEP? Otherwise I feel that listing a platform as tier 3 just says, "there's some code in `main` for it, but we have no clue if it works and we won't necessarily try to make it work." And if that's the case then why do we need to keep the code around and the cost of readability of our code base? > > Removing code from Python means in practice that the support *can* > still continue, but outside of the Git upstream repository: in a fork > instead. > > For me the main threat of (adding a platform to) Tier 3 is the risk > that we might never ever able to drop support for these platforms. PEP > 11 would be used by users as a holy document. Maybe we should be clear > that Tier 3 is not a strong warranty of long term support, but is just > a weak status. For example, put a time bomb: if no developer was > available in the last 12 month to fix regressions, drop the platform > for Tier 3. > But without a buildbot how do we know when there are regressions and when that regression occurred? I wouldn't even know when those 12 months started w/ this proposal. > > -- > > I'm thinking at these platforms for Tier 3: > > * AIX 6.4 and newer (has a buildbot) > * Android API 24 > * FreeBSD > * OpenBSD > * NetBSD > * s390x arch > * Solaris (has a buildbot) > > I would prefer to put FreeBSD and s390x in Tier 3 rather than Tier 2. > > Users of these platforms and contributors who added support for these > platforms are going to be grumpy if we drop such platform without any > warning or process. > > Android support seems to be stale for now. But I would prefer to keep > it for now. > > -- > > Last year, I proposed to drop immediately Solaris support (remove code): > > https://mail.python.org/archives/list/[email protected]/thread/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/ > > I read that Solaris was no longer maintained by Oracle. I was wrong. > Moreover, many Python users on Solaris started to complained loudly. > Not only Solaris is maintained, but it's also under active > development. After this thread, Oracle contributed Solaris patches to > Python, and set up a buildbot! > If you're referring to https://buildbot.python.org/all/#/workers/47 then it hasn't passed a build in months. > > I suggest thinking twice before adding a platform to Tier 3. Adding it > is easy. But there will always be at least *one* very grumpy Python > user of this platform who will fight to death to keep his old precious > unmaintained broken platform, even if no one else in the world has > access to the hardware (no longer sold) and no one is able to fix > regressions. > > -- > > For now, I would prefer to *not* add the following platforms to Tier > 3. Keep them in the gray area of "unsupported" platforms. > > * DOS > * Cygwin > * HP-UX > * MinGW > * VMS (OpenVMS): https://vmspython.org/ > > Time to time, I merge HP-UX fixes if someone proposes a fix and I have > some free cycle to review it. Once, I fixed one Unicode issue specific > to HP-UX without having access to HP-UX. It's not the most efficient > development method for me: it requires a lot of back and forth > exchanges with a developer having access to this platform. I don't > want to list HP-UX in Tier 3: I don't have access to HP-UX. > > -- > > My notes on platforms supported by Python: > https://pythondev.readthedocs.io/platforms.html > Here's my counter-proposal. Tier 3: - 1 core dev - Buildbot - SC/consensus approval to be added/removed - Can
[python-committers] Re: Consider adding a Tier 3 to tiered platform support
On Fri, Apr 1, 2022 at 12:22 PM Brett Cannon wrote: > > On Thu, Mar 31, 2022 at 4:40 PM Victor Stinner > wrote: > >> Hi, >> >> I don't think that the current PEP 11 draft (*) describes correctly >> the current status of a bunch of platforms which are not "actively" >> supported. I like to call these plaforms as "best effort support" >> platforms. I propose considering adding an explicit "Tier 3" to PEP >> 11. >> >> (*) https://github.com/python/peps/pull/2442/ >> >> Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust >> codebase has support for, but which the Rust project does not build or >> test automatically, so they may or may not work." >> >> Tier 3 requirements would be *very weak*: >> >> * No buildbot requirement >> * No assigned core dev needed >> * Don't revert a change breaking a Tier 3 platform >> * Don't hold a Python release if a Tier 3 platform is broken >> > >> Currently, the "All other platforms" section is quite clear: code can >> be removed anytime: >> >> "Code changes to platforms not listed in the above tiers may rejected >> or removed from the code base *without a deprecation process* if they >> cause a maintenance burden or obstruct general improvements." >> >> The only difference between "Tier 3" and "All other platforms" would >> be that removing a platform from Tier 3 require a process. I'm not >> sure if a deprecation is needed. But we have to go through a >> discussion and someone (SC?) has to decide if it's ok to drop it >> (remove code). >> > > If there's no buildbot making sure the platform works and no core dev > trying to keep it working, then what's the point of listing the platform in > the PEP? Otherwise I feel that listing a platform as tier 3 just says, > "there's some code in `main` for it, but we have no clue if it works and we > won't necessarily try to make it work." And if that's the case then why do > we need to keep the code around and the cost of readability of our code > base? > > >> >> Removing code from Python means in practice that the support *can* >> still continue, but outside of the Git upstream repository: in a fork >> instead. >> >> For me the main threat of (adding a platform to) Tier 3 is the risk >> that we might never ever able to drop support for these platforms. PEP >> 11 would be used by users as a holy document. Maybe we should be clear >> that Tier 3 is not a strong warranty of long term support, but is just >> a weak status. For example, put a time bomb: if no developer was >> available in the last 12 month to fix regressions, drop the platform >> for Tier 3. >> > > But without a buildbot how do we know when there are regressions and when > that regression occurred? I wouldn't even know when those 12 months started > w/ this proposal. > > >> >> -- >> >> I'm thinking at these platforms for Tier 3: >> >> * AIX 6.4 and newer (has a buildbot) >> * Android API 24 >> * FreeBSD >> * OpenBSD >> * NetBSD >> * s390x arch >> * Solaris (has a buildbot) >> >> I would prefer to put FreeBSD and s390x in Tier 3 rather than Tier 2. >> >> Users of these platforms and contributors who added support for these >> platforms are going to be grumpy if we drop such platform without any >> warning or process. >> >> Android support seems to be stale for now. But I would prefer to keep >> it for now. >> >> -- >> >> Last year, I proposed to drop immediately Solaris support (remove code): >> >> https://mail.python.org/archives/list/[email protected]/thread/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/ >> >> I read that Solaris was no longer maintained by Oracle. I was wrong. >> Moreover, many Python users on Solaris started to complained loudly. >> Not only Solaris is maintained, but it's also under active >> development. After this thread, Oracle contributed Solaris patches to >> Python, and set up a buildbot! >> > > If you're referring to https://buildbot.python.org/all/#/workers/47 then > it hasn't passed a build in months. > > >> >> I suggest thinking twice before adding a platform to Tier 3. Adding it >> is easy. But there will always be at least *one* very grumpy Python >> user of this platform who will fight to death to keep his old precious >> unmaintained broken platform, even if no one else in the world has >> access to the hardware (no longer sold) and no one is able to fix >> regressions. >> >> -- >> >> For now, I would prefer to *not* add the following platforms to Tier >> 3. Keep them in the gray area of "unsupported" platforms. >> >> * DOS >> * Cygwin >> * HP-UX >> * MinGW >> * VMS (OpenVMS): https://vmspython.org/ >> >> Time to time, I merge HP-UX fixes if someone proposes a fix and I have >> some free cycle to review it. Once, I fixed one Unicode issue specific >> to HP-UX without having access to HP-UX. It's not the most efficient >> development method for me: it requires a lot of back and forth >> exchanges with a developer having access to this platform. I don't >> want to list HP-UX in Tier 3: I don't have access to HP-UX. >> >> -- >> >> M
[python-committers] Re: Consider adding a Tier 3 to tiered platform support
I like your proposal better than mine :-) I agree that my Tier 3's
constraints were too weak :-(
On Fri, Apr 1, 2022 at 9:22 PM Brett Cannon wrote:
>> For me the main threat of (adding a platform to) Tier 3 is the risk
>> that we might never ever able to drop support for these platforms. PEP
>> 11 would be used by users as a holy document. Maybe we should be clear
>> that Tier 3 is not a strong warranty of long term support, but is just
>> a weak status. For example, put a time bomb: if no developer was
>> available in the last 12 month to fix regressions, drop the platform
>> for Tier 3.
>
> But without a buildbot how do we know when there are regressions and when
> that regression occurred? I wouldn't even know when those 12 months started
> w/ this proposal.
After sending my email, I realized that "the grumpy user" would use
the lack of buildbot as an argument to keep the platform: the platform
is working since there is no red buildbot!
Yeah, sadly, I have no idea of the current status of the Android
support. Maybe it's mostly ok. Maybe it's badly broken.
>> I'm thinking at these platforms for Tier 3:
>>
>> * AIX 6.4 and newer (has a buildbot)
>> * Android API 24
>> * FreeBSD
>> * OpenBSD
>> * NetBSD
>> * s390x arch
>> * Solaris (has a buildbot)
>
>
> Here's my counter-proposal.
>
> Tier 3:
> - 1 core dev
Yeah sadly, it's hard to find 2 volunteers for these less common platforms.
> - Buildbot
> - SC/consensus approval to be added/removed
IMO a platform must have a running buildbot and the buildbot must not
fail for at least 2 weeks to be considered as good enough to enter
Tier 3. It should be a pre-condition to consider adding a platform to
a Tier. That's different from the current PEP 11 which says that
"having a buildbot" is enough, it doesn't specify if it should work or
not.
> - Can have a directory in `Tools/` to maintain things such as build configs
> (see https://github.com/python/cpython/tree/main/Tools/wasm as an example)
PPC64 AIX, x86-64 FreeBSD, s390x Linux and SPARCv9 Solaris have a buildbot.
I'm ok to maintain ("best effort"!) FreeBSD and s390x Linux.
I'm not interested to maintain AIX and Solaris. If no core dev is
volunteer to maintain them, according to your proposal, they don't
belong to Tier 3.
Maybe we should write down that a broken Tier 3 platform doesn't
qualify to revert a Python commit.
> All tiers:
> - If a platform is not supported and stable by beta, there will be an
> announcement (probably in What's New) about how the platform is slated to not
> be officially supported in this release and we plan to drop support
> completely for the platform in the final release unless the situation is
> resolved by RC.
> That would give the community 3 months between b1 and rc1 to work with the
> core dev who has volunteered to make that platform work again (...)
IMO it's a good rule and it's good to have it written down to avoid
complains later.
> We can also give all tier 3 platforms a "pass" for 3.11 where we won't
> trigger any of this until 3.12b1 so there's enough time to line up a Buildbot
> and core dev.
Honestly, AIX and Solaris are in a bad shape. Tests are failing for a
several weeks as you noticed. If the PEP 11 is deeply updated, it's a
good opportunity to start from a smaller but better platform subset.
Adding AIX and Solaris to Tier 3 can be considered later, once all
issues are fixed and a *core dev* will be actively fixing regressions
specific to these platforms.
Next question: should we drop buildbots when the SC decides to no
longer support the platform? For a new platform which is not in Tier 3
yet, how can it enter Tier 3 if it doesn't have a buildbot?
In the past, what I did is to disable email notficiations for AIX
because no core dev was fixing issues. The buildbot was still running,
bugs were known for months, but nobody fixed them.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/GMEPCZP5M24DYQJEG4EBJIAO4D5B7SMR/
Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Dependabot actions on my cpython fork
I have a cpython fork on my github account - every so often, dependabot kicks in and runs a whole load of actions, which I don't need. I'm not sure how I can switch these off, short of removing the .github directory (which would mean my fork has diverged from upstream, which I'm therefore reluctant to do). Is there a way of stopping these jobs running? APart from the annoying emails that I just ignore, it's a waste of computing resources for no good reason. Thanks, Paul ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2X3EIPQELPKDHOE2PPT4USZATZZA256W/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Consider adding a Tier 3 to tiered platform support
On 01/04/2022 01.40, Victor Stinner wrote: Hi, I don't think that the current PEP 11 draft (*) describes correctly the current status of a bunch of platforms which are not "actively" supported. I like to call these plaforms as "best effort support" platforms. I propose considering adding an explicit "Tier 3" to PEP 11. (*) https://github.com/python/peps/pull/2442/ Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work." Tier 3 requirements would be *very weak*: * No buildbot requirement * No assigned core dev needed * Don't revert a change breaking a Tier 3 platform * Don't hold a Python release if a Tier 3 platform is broken As Brett pointed out a tier 3 platform does not make much sense if we have no means to test the platform. I also would like to nudge vendors to contribute resources like build bots or engineering time. We want a low bar for contributions. No bar is too low. :) How about: * a buildbot is required. For a transition period a public CI system, that runs Python's test suite at least once per day, is also acceptable. * at least one active contributor who acts as a point of contact, monitors CI and provides fixes in a timely fashion. Christian ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CUBFMUL7SQZ6M2K6WK7XD2K2FGHDOUUJ/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Dependabot actions on my cpython fork
This was just discussed on Discord. The upstream issue is https://github.com/dependabot/dependabot-core/issues/2804 On Fri, Apr 1, 2022 at 14:19 Paul Moore wrote: > I have a cpython fork on my github account - every so often, > dependabot kicks in and runs a whole load of actions, which I don't > need. I'm not sure how I can switch these off, short of removing the > .github directory (which would mean my fork has diverged from > upstream, which I'm therefore reluctant to do). > > Is there a way of stopping these jobs running? APart from the annoying > emails that I just ignore, it's a waste of computing resources for no > good reason. > > Thanks, > Paul > ___ > python-committers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/2X3EIPQELPKDHOE2PPT4USZATZZA256W/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/PLYALO5UGLWNJPBKM2IXJK2ED4XVR5CB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Consider adding a Tier 3 to tiered platform support
On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes wrote: > How about: > > * a buildbot is required. For a transition period a public CI system, > that runs Python's test suite at least once per day, is also acceptable. > > * at least one active contributor who acts as a point of contact, > monitors CI and provides fixes in a timely fashion. Sadly, I'm not sure that a regular contributor is enough to get fixes merged even fixes are written. Maybe it's better to require one core dev per Tier 3 platform. What if tomorrow someone sets up a MinGW buildbot. Is it enough to promote MinGW as Tier 3? There are many MinGW patches awaiting in the bug tracker for *years* and nobody is available to review and merged them. (I didn't check recently, maybe some of them have been merged in the meanwhile?) For the buildbot, IMO it's important that the whole test suite pass. I'm fine with skipping a large number of tests. But a single failure makes a buildbot really annoying, barely usuable, because buildbots are unable to say if a change adds more errors than previously. It's a boolean: either all tests pass, or "at least one test fails": you have to dig into logs to know the exact number :-( Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/MHOVM2A2QTICTOIRAWWG3RIUPI4BKQKI/ Code of Conduct: https://www.python.org/psf/codeofconduct/
