On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon <email@example.com> wrote:
> On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner <firstname.lastname@example.org> wrote:
>> I dislike the Tier 1 rule "All core developers are responsible to keep
>> these platforms, and thus ``main``, working."
>> In my experience, "Everyone is reponsible" means in practice "nobody
>> is responsible".
> I don't think that applies here as you shouldn't even be merging a PR if it breaks CI for these platforms. And if CI isn't good enough then we should fix that.
> But tier 1 is the CI we run on PRs, not in the Buildbot fleet.
There is an old debate about differences between GitHub Actions and Buildbots:
* Buildbots run the test suite with "-u all" option. On Windows,
Python is built in debug mode.
* GHA uses "-u all,-cpu". On Windows, Python is built in release mode
(I think that changed last change after the 3rd buildbot failure not
catched by GHA but buildbots).
A small number of regressions are not catched by GHA because of these
minor differences. It's a trade-off to keep the workflow efficient (be
able to merge a PR as soon as possible).
I'm fine with this trade-off. But we must keep an eye on buildbots,
otherwise more changes are merged on top of the change introducing the
If you consider that GHA are enough to prevent regressions for Tier 1,
does it mean that the "macOS" job must become mandatory? It's a x86_64
platform. In my experience, this job is too slow and less reliable
than other GHA jobs. Maybe macOS should be pushed to Tier 2. Fixing
all macOS before a Python release is fine. But during the devcycle,
sometimes there are no enough available core devs to fix macOS
specific issues. Correct me if I'm wrong. I'm talking about the strong
Tier 1 requirements about the short delay to fix a regression, or