[python-committers] Re: Do people still find this mailing list useful?

[Brett Cannon]

Based on the replies here and discussing things with the steering council,
we decided we should archive the list.

On Sat, Jul 8, 2023 at 2:57 AM Marc-Andre Lemburg  wrote:

> On 07.07.2023 12:11, Marc-Andre Lemburg wrote:
>
> On 07.07.2023 01:44, Brett Cannon wrote:
>
> I didn't set up the instance (it's hosted by Discourse for us for free),
> but Łukasz or Pablo might know. Else we can ask the infrastructure team at
> the PSF.
>
> I reached out to Ee to see whether anything can be or is already done.
>
> Ee confirmed that we have a daily Discourse database backup on PSF S3, so
> the concern is resolved.
>
>
> On Tue, Jul 4, 2023 at 11:43 AM C.A.M. Gerlach 
>  wrote:
>
>> Good point. The PostgreSQL database that stores everything can be backed
>> up, stored as a file anywhere and restored fairly easily:
>> https://meta.discourse.org/t/122710 I'm only a mod (not an admin), so I
>> don't know if we're actually doing it right now, but maybe Brett or one of
>> the other admins does—might be a good idea to do regularly just in case.
>>
>> Besides being restored to another Discourse instance (including self
>> hosted), the db schema is documented as comments at the bottom of each file
>> in the `app/models` directory, e.g. for posts:
>> https://github.com/discourse/discourse/blob/main/app/models/post.rb#L1257-L1327
>> and thus one could browsed, query and extract, e.g. an archive of posts via
>> a PostgreSQL client or a script, as well as in the official first-party
>> maintained data explorer plugin that runs inside the instance:
>> https://meta.discourse.org/t/discourse-data-explorer/32566
>>
>> Discourse also has an API: https://docs.discourse.org/ , and you can get
>> the data on any page as JSON via adding `.json` to the URL,
>> https://discuss.python.org/t/27957.json, so the public data could also
>> be scraped and archived that way by anyone interested if desired (just like
>> the ML can).
>>
>> Does that help address your concern?
>>
>> Thanks,
>> CAM
>>
>> *C.A.M. Gerlach*
>>
>>
>> On Tue, Jul 4, 2023 at 4:57 AM Marc-Andre Lemburg  wrote:
>>
>>> The only concern I have with moving off of the MLs and to Discourse is
>>> archiving of messages.
>>>
>>> With MLs, the archiving process is pretty straight forward and built
>>> into Mailman, but for Discourse this is less obvious.
>>>
>>> Do we have a solution to archiving Discourse content in place which is
>>> under PSF control ? (AFAIK, we are using a hosted Discource installation)
>>>
>>> Thanks.
>>>
>>> On 04.07.2023 06:57, C.A.M. Gerlach wrote:
>>> > FWIW, +1 to archiving to reduce duplication. If decided, I can help
>>> out
>>> > making the appropriate devguide, PEP, etc. changes, as I've done for
>>> > several previous transitions now.
>>> >
>>> > Thanks,
>>> > CAM
>>> >
>>> > /C.A.M. Gerlach/
>>> >
>>> >
>>> > On Mon, Jul 3, 2023 at 2:15 PM Brett Cannon >> > <mailto:br...@python.org>> wrote:
>>> >
>>> > The question has come up as to whether people still find this
>>> > mailing list useful enough to keep around. Looking at the archive
>>> > (
>>> https://mail.python.org/archives/list/python-committers@python.org/latest
>>> <
>>> https://mail.python.org/archives/list/python-committers@python.org/latest>),
>>> this list seems to be used for two things:
>>> >
>>> >  1. Announcing new releases
>>> >  2. Announcing new core developers
>>> >
>>> > In both cases the things are announced (at least) at
>>> > discuss.python.org <http://discuss.python.org>, and so are not
>>> > exclusive to this list.
>>> >
>>> > So, do people find this list useful enough to keep around, or
>>> should
>>> > we archive it?
>>> > ___
>>> > python-committers mailing list -- python-committers@python.org
>>> > <mailto:python-committers@python.org>
>>> > To unsubscribe send an email to python-committers-le...@python.org
>>> > <mailto:python-committers-le...@python.org>
>>> >
>>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>>> > <
>>> https://mail.python.org/mailman3/lists/python-committers.python.org/>
>>> &g

[python-committers] Re: Do people still find this mailing list useful?

[Brett Cannon]

I didn't set up the instance (it's hosted by Discourse for us for free),
but Łukasz or Pablo might know. Else we can ask the infrastructure team at
the PSF.

On Tue, Jul 4, 2023 at 11:43 AM C.A.M. Gerlach 
wrote:

> Good point. The PostgreSQL database that stores everything can be backed
> up, stored as a file anywhere and restored fairly easily:
> https://meta.discourse.org/t/122710 I'm only a mod (not an admin), so I
> don't know if we're actually doing it right now, but maybe Brett or one of
> the other admins does—might be a good idea to do regularly just in case.
>
> Besides being restored to another Discourse instance (including self
> hosted), the db schema is documented as comments at the bottom of each file
> in the `app/models` directory, e.g. for posts:
> https://github.com/discourse/discourse/blob/main/app/models/post.rb#L1257-L1327
> and thus one could browsed, query and extract, e.g. an archive of posts via
> a PostgreSQL client or a script, as well as in the official first-party
> maintained data explorer plugin that runs inside the instance:
> https://meta.discourse.org/t/discourse-data-explorer/32566
>
> Discourse also has an API: https://docs.discourse.org/ , and you can get
> the data on any page as JSON via adding `.json` to the URL,
> https://discuss.python.org/t/27957.json, so the public data could also be
> scraped and archived that way by anyone interested if desired (just like
> the ML can).
>
> Does that help address your concern?
>
> Thanks,
> CAM
>
> *C.A.M. Gerlach*
>
>
> On Tue, Jul 4, 2023 at 4:57 AM Marc-Andre Lemburg  wrote:
>
>> The only concern I have with moving off of the MLs and to Discourse is
>> archiving of messages.
>>
>> With MLs, the archiving process is pretty straight forward and built
>> into Mailman, but for Discourse this is less obvious.
>>
>> Do we have a solution to archiving Discourse content in place which is
>> under PSF control ? (AFAIK, we are using a hosted Discource installation)
>>
>> Thanks.
>>
>> On 04.07.2023 06:57, C.A.M. Gerlach wrote:
>> > FWIW, +1 to archiving to reduce duplication. If decided, I can help out
>> > making the appropriate devguide, PEP, etc. changes, as I've done for
>> > several previous transitions now.
>> >
>> > Thanks,
>> > CAM
>> >
>> > /C.A.M. Gerlach/
>> >
>> >
>> > On Mon, Jul 3, 2023 at 2:15 PM Brett Cannon > > <mailto:br...@python.org>> wrote:
>> >
>> > The question has come up as to whether people still find this
>> > mailing list useful enough to keep around. Looking at the archive
>> > (
>> https://mail.python.org/archives/list/python-committers@python.org/latest
>> <
>> https://mail.python.org/archives/list/python-committers@python.org/latest>),
>> this list seems to be used for two things:
>> >
>> >  1. Announcing new releases
>> >  2. Announcing new core developers
>> >
>> > In both cases the things are announced (at least) at
>> > discuss.python.org <http://discuss.python.org>, and so are not
>> > exclusive to this list.
>> >
>> > So, do people find this list useful enough to keep around, or should
>> > we archive it?
>> > ___
>> > python-committers mailing list -- python-committers@python.org
>> > <mailto:python-committers@python.org>
>> > To unsubscribe send an email to python-committers-le...@python.org
>> > <mailto:python-committers-le...@python.org>
>> >
>> https://mail.python.org/mailman3/lists/python-committers.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/WAVEXV3FAK6IFMXTVO7PRNYOY66NBP2F/
>> <
>> https://mail.python.org/archives/list/python-committers@python.org/message/WAVEXV3FAK6IFMXTVO7PRNYOY66NBP2F/
>> >
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>> > <https://www.python.org/psf/codeofconduct/>
>> >
>> >
>> > ___
>> > 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-committ

[python-committers] Do people still find this mailing list useful?

[Brett Cannon]

The question has come up as to whether people still find this mailing list
useful enough to keep around. Looking at the archive (
https://mail.python.org/archives/list/python-committers@python.org/latest),
this list seems to be used for two things:

   1. Announcing new releases
   2. Announcing new core developers

In both cases the things are announced (at least) at discuss.python.org,
and so are not exclusive to this list.

So, do people find this list useful enough to keep around, or should we
archive it?
___
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/WAVEXV3FAK6IFMXTVO7PRNYOY66NBP2F/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Poll at discuss.python.org on free-threading and PEP 703

[Brett Cannon]

https://discuss.python.org/t/poll-feedback-to-the-sc-on-making-cpython-free-threaded-and-pep-703/28540/

P.S. I personally would advise people keep an eye on
https://discuss.python.org/c/committers/ for stuff as not everyone
remembers this mailing list even exists (I'm personally posting here just
because Guido said someone didn't know about the poll). I have opened
https://github.com/python/steering-council/issues/198 to have the SC talk
about this as I'm not sure if we formally declared anything like we did for
python-dev for python-committers (I honestly thought we had).
___
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/6AIPIUJYPGKJHPYX5TNL7RNPEBNQDHDJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome C.A.M. Gerlach to the team!

[Brett Cannon]

___
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/5B72UX2WDNF4DXZ4HMAE6W76ZZHBY3MS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Barney Gale to the team!

[Brett Cannon]

___
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/3UFKPK4AHK6NLOAVOSPMZPVB345PUZP5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Carl Meyer to the team!

[Brett Cannon]

___
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/BR7LD6LODY6EYFC3BQXS7B4X33CELAGZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Pradyun to the team!

[Brett Cannon]

___
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/J6GGU6LLPYX3HLHFEEK6RECVSK3UIYPQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Shantanu Jain to the team!

[Brett Cannon]

___
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/7AMWXRS52QOKQENG56I4V4J7DKP2W4SW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Kumar to the team!

[Brett Cannon]

___
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/LI4BQ46VEV6K37ZYAFTRH5UKZIXKLRHJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Hugo to the team!

[Brett Cannon]

___
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/NIAXVMCZ66RHW6S5KIPGKTOSLZC3N45P/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Alex Waygood to the team!

[Brett Cannon]

___
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/FFK5OBLSR4IEL6Z3MUXBQNOQ6BZ56NWF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Filipe Lains to the team!

[Brett Cannon]

___
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/IAKH2T2NXWK77XMTBFBOKNWR2S7LTEAU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

FYI there are now tier labels for the buildbots and the links have been
added to the PEP.

https://peps.python.org/pep-0011/#support-tiers
Tier 2:
https://buildbot.python.org/all/#/builders?tags=%2B3.x=%2Btier-2
Tier 3:
https://buildbot.python.org/all/#/builders?tags=%2B3.x=%2Btier-3

(Tier 1 is covered by
https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted
.)

On Thu, Mar 10, 2022 at 3:35 PM Brett Cannon  wrote:

> I brought this up on python-dev at
> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> , and the feedback seemed supportive. As such, I am bringing a draft of
> what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
> for people to help me fill in to see how this will look overall.
>
> For any platform(s) you support, please reply with any relevant details
> that should be added to the relevant tables below. Once I have these
> details I will loop back with the proposed update to PEP 11 and make sure
> everyone is still on board with the proposal.
>
> =
> Tiers
> =
>
> 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.
>
> === =
> Target Triple   Notes
> === =
> i686-windows-msvc
> x86_64-windows-msvc
> x86_64-apple-darwin macOS 11
> x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
> === =
>
> .. [ubuntu-20_01]
> https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4
>
>
> Tier 2
> ==
>
> - Must have a stable buildbot.
> - At least **two** core developers are signed up to support the platform.
> - Changes which break any of these platforms are to be reverted within 24
> hours.
> - Failures of these platforms block a release.
> - Promotion of this tier requires consensus/SC approval.
>
> == ==
> == 
> Target Triple  Notes  Buildbot
>   Contacts
> == ==
> == 
> aarch64-apple-darwin   XXX
> https://buildbot.python.org/all/#/builders/725 XXX
> aarch64-linux-gnu  glibc XXX [fedora-stable]_
> https://buildbot.python.org/all/#/builders/125 XXX
>glibc 2.28 [RHEL8]_
> https://buildbot.python.org/all/#/builders/529 XXX
> aarch64-windows-msvc   XXX
> https://buildbot.python.org/all/#/builders/729 XXX
> powerpc64-linux-gnuglibc XXX
> https://buildbot.python.org/all/#/builders/237 XXX
> powerpcle-linux-gnuglibc XXX
> https://buildbot.python.org/all/#/builders/90  XXX
> s309x-linux-gnuglibc XXX
> https://buildbot.python.org/all/#/builders/223 XXX
>glibc 2.28 [RHEL8]_
> https://buildbot.python.org/all/#/builders/509 XXX
>glibc 2.17 [RHEL7]_
> https://buildbot.python.org/all/#/builders/179 XXX
> x86_64-linux-gnu   glibc 2.17 [RHEL7]_
> https://buildbot.python.org/all/#/builders/15  XXX
> x86_64-unknown-freebsd XXX
> https://buildbot.python.org/all/#/builders/172 XXX
> == ==
> == 
>
> .. [fedora-stable] XXX
> .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8
> .. [RHEL7]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc
>
>
> Tier 3
> ==
>
> - Must have a stable buildbot.
> - Code may be checked into ``main`` for the platform.
> - At least **one** core developer is signed up to support the platform.
> - Test failures do **not** block releases.
> - Promotion to this tier is self-service.
>
> = ==
> == 
> Target Triple Notes  Buildbot
>   Contacts
> ===== ==
> == 
> wasm32-unknown-emscripten XXXXXX
>  Brett Cannon, Christian Heimes
> wasm32-unknown-wasi   XXX  

[python-committers] Welcome Erlend Aasland to the team!

[Brett Cannon]

EOM
___
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/HHRAUB6RFCHQDTZDH5LQ7AVJE5WDVYBJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: New triagers: Slateny, Shantanu, CAM Gerlach, Adam Turner, Pradyun Gedam, Ned Batchelder

[Brett Cannon]

On Mon, May 2, 2022 at 4:12 PM Ethan Furman  wrote:

> On 5/2/22 16:00, Jelle Zijlstra wrote:
>
> > We have added several new triagers today:
>
> Do triagers have access to this list?
>

Nope, core devs only.

-Brett


>
> Regardless, congratulations!!
>
> --
> ~Ethan~
> ___
> 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/PAD3KQER3LZZGXNR4LQXSKX5MGFXQI47/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/OYUR3IC4UYP6A77NK7DKR53IYEAVK4F7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Brett Cannon]

And now the PR is merged! https://github.com/python/peps/pull/2442

Thanks to everyone who provided input! When I get a chance I will work to
get tier labels added to the appropriate buildbots and then update the PEP
to link to those queries instead of individual buildbots.

On Mon, Apr 11, 2022 at 1:31 PM Brett Cannon  wrote:

>
>
> On Sat, Apr 9, 2022 at 5:04 AM M.-A. Lemburg  wrote:
>
>> On 09.04.2022 02:13, Brett Cannon wrote:
>> >
>> >
>> > On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg > > <mailto:m...@egenix.com>> wrote:
>> >
>> > On 06.04.2022 20:48, Brett Cannon wrote:
>> >  > Last chance on whether my tier 3 proposal make sense! I will take
>> > silence as
>> >  > acceptance and plan to convert any current tier 2 platform with a
>> > single core
>> >  > dev to tier 3 and then ask the SC to approve/reject the list of
>> > platforms. I
>> >  > will also update the PEP about expectations of when things must
>> > be considered
>> >  > stable before b1, else a warning goes out that a platform risks
>> > being dropped in
>> >  > the RC (regardless of tier).
>> >  >
>> >  > I will also be filling out the tiers to include the vendor, but I
>> > will be using
>> >  > `unknown` instead of `*` since I haven't come across the latter
>> > online while I
>> >  > come across the former regularly (e.g.
>> >  > https://doc.rust-lang.org/nightly/rustc/platform-support.html).
>> >
>> > Could you please post the current proposal somewhere to read in
>> > one complete piece ? It's become hard to figure out what is on
>> > the table at the moment and the PR also doesn't appear to be
>> > up to date:
>> >
>> > https://github.com/python/peps/pull/2442/files
>> >
>> >
>> > The PR is now up-to-date! For ease of reference, here's the critical
>> part:
>>
>> Thanks, Brett.
>>
>> > Support tiers
>> > =
>> >
>> > Platform support is broken down into *tiers*. Each tier comes with
>> > different requirements which lead to different promises being made
>> > about support.
>> >
>> > To be promoted to a tier, steering council support is required and is
>> > expected to be driven by team consensus. Demotion to a lower tier
>> > occurs then the requirements of the current tier are no longer met for
>> > a platform for an extended period of time based on the judgment of
>> > the release manager or steering council. For platforms which no longer
>> > meet the requirements of any tier by b1 of a new feature release, an
>> > announcement will be made to warn the community of the pending removal
>> > of support for the platform (e.g. in the b1 announcement). If the
>> > platform is not brought into line for at least one of the tiers by the
>> > first release candidate, it will be listed as unsupported in this PEP.
>> >
>> > Tier 1
>> > --
>> >
>> > - `CI 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 should be fixed or reverted immediately.
>> > - All core developers are responsible to keep ``main``, and thus these
>> >platforms, working.
>> > - Failures on these platforms **block a release**.
>> >
>> >  =
>> > Target TripleNotes
>> >  =
>> > i686-pc-windows-msvc
>> > x86_64-pc-windows-msvc
>> > x86_64-apple-darwin  BSD libc, clang
>> > x86_64-unknown-linux-gnu glibc, gcc
>> >  =
>> >
>> >
>> > Tier 2
>> > --
>> >
>> > - Must have a reliable buildbot.
>> > - At least **two** core developers are signed up to support the
>> platform.
>> > - Changes which break any of these platforms are to be **fixed or
>> >reverted within 24 hours**.
>> > - Failures on these platforms **block a release**.
>> >
>> > === ==
>> > == 
>> > Target Tripl

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Brett Cannon]

On Sat, Apr 9, 2022 at 5:04 AM M.-A. Lemburg  wrote:

> On 09.04.2022 02:13, Brett Cannon wrote:
> >
> >
> > On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg  > <mailto:m...@egenix.com>> wrote:
> >
> > On 06.04.2022 20:48, Brett Cannon wrote:
> >  > Last chance on whether my tier 3 proposal make sense! I will take
> > silence as
> >  > acceptance and plan to convert any current tier 2 platform with a
> > single core
> >  > dev to tier 3 and then ask the SC to approve/reject the list of
> > platforms. I
> >  > will also update the PEP about expectations of when things must
> > be considered
> >  > stable before b1, else a warning goes out that a platform risks
> > being dropped in
> >  > the RC (regardless of tier).
> >  >
> >  > I will also be filling out the tiers to include the vendor, but I
> > will be using
> >  > `unknown` instead of `*` since I haven't come across the latter
> > online while I
> >  > come across the former regularly (e.g.
> >  > https://doc.rust-lang.org/nightly/rustc/platform-support.html).
> >
> > Could you please post the current proposal somewhere to read in
> > one complete piece ? It's become hard to figure out what is on
> > the table at the moment and the PR also doesn't appear to be
> > up to date:
> >
> > https://github.com/python/peps/pull/2442/files
> >
> >
> > The PR is now up-to-date! For ease of reference, here's the critical
> part:
>
> Thanks, Brett.
>
> > Support tiers
> > =
> >
> > Platform support is broken down into *tiers*. Each tier comes with
> > different requirements which lead to different promises being made
> > about support.
> >
> > To be promoted to a tier, steering council support is required and is
> > expected to be driven by team consensus. Demotion to a lower tier
> > occurs then the requirements of the current tier are no longer met for
> > a platform for an extended period of time based on the judgment of
> > the release manager or steering council. For platforms which no longer
> > meet the requirements of any tier by b1 of a new feature release, an
> > announcement will be made to warn the community of the pending removal
> > of support for the platform (e.g. in the b1 announcement). If the
> > platform is not brought into line for at least one of the tiers by the
> > first release candidate, it will be listed as unsupported in this PEP.
> >
> > Tier 1
> > --
> >
> > - `CI 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 should be fixed or reverted immediately.
> > - All core developers are responsible to keep ``main``, and thus these
> >platforms, working.
> > - Failures on these platforms **block a release**.
> >
> >  =
> > Target TripleNotes
> >  =
> > i686-pc-windows-msvc
> > x86_64-pc-windows-msvc
> > x86_64-apple-darwin  BSD libc, clang
> > x86_64-unknown-linux-gnu glibc, gcc
> >  =
> >
> >
> > Tier 2
> > --
> >
> > - Must have a reliable buildbot.
> > - At least **two** core developers are signed up to support the platform.
> > - Changes which break any of these platforms are to be **fixed or
> >reverted within 24 hours**.
> > - Failures on these platforms **block a release**.
> >
> > === ==
> > == 
> > Target Triple   Notes  Buildbot
> >Contacts
> > === ==
> > == 
> > aarch64-apple-darwinclang
> > https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald
> > Oussoren, Dong-he Na
> > aarch64-unknown-linux-gnu   glibc, gcc
> > https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor
> Stinner
> >
> >  glibc, clang
> > https://buildbot.python.org/all/#/builders/234 

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Brett Cannon]

On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg  wrote:

> On 06.04.2022 20:48, Brett Cannon wrote:
> > Last chance on whether my tier 3 proposal make sense! I will take
> silence as
> > acceptance and plan to convert any current tier 2 platform with a single
> core
> > dev to tier 3 and then ask the SC to approve/reject the list of
> platforms. I
> > will also update the PEP about expectations of when things must be
> considered
> > stable before b1, else a warning goes out that a platform risks being
> dropped in
> > the RC (regardless of tier).
> >
> > I will also be filling out the tiers to include the vendor, but I will
> be using
> > `unknown` instead of `*` since I haven't come across the latter online
> while I
> > come across the former regularly (e.g.
> > https://doc.rust-lang.org/nightly/rustc/platform-support.html).
>
> Could you please post the current proposal somewhere to read in
> one complete piece ? It's become hard to figure out what is on
> the table at the moment and the PR also doesn't appear to be
> up to date:
>
> https://github.com/python/peps/pull/2442/files


The PR is now up-to-date! For ease of reference, here's the critical part:

Support tiers
=

Platform support is broken down into *tiers*. Each tier comes with
different requirements which lead to different promises being made
about support.

To be promoted to a tier, steering council support is required and is
expected to be driven by team consensus. Demotion to a lower tier
occurs then the requirements of the current tier are no longer met for
a platform for an extended period of time based on the judgment of
the release manager or steering council. For platforms which no longer
meet the requirements of any tier by b1 of a new feature release, an
announcement will be made to warn the community of the pending removal
of support for the platform (e.g. in the b1 announcement). If the
platform is not brought into line for at least one of the tiers by the
first release candidate, it will be listed as unsupported in this PEP.

Tier 1
--

- `CI 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 should be fixed or reverted immediately.
- All core developers are responsible to keep ``main``, and thus these
  platforms, working.
- Failures on these platforms **block a release**.

 =
Target TripleNotes
 =
i686-pc-windows-msvc
x86_64-pc-windows-msvc
x86_64-apple-darwin  BSD libc, clang
x86_64-unknown-linux-gnu glibc, gcc
 =


Tier 2
--

- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be **fixed or
  reverted within 24 hours**.
- Failures on these platforms **block a release**.

=== ==
== 
Target Triple   Notes  Buildbot
  Contacts
=== ==
== 
aarch64-apple-darwinclang
https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren,
Dong-he Na
aarch64-unknown-linux-gnu   glibc, gcc
https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner

glibc, clang
https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P.
Smith
powerpcle-unknown-linux-gnu glibc, gcc
https://buildbot.python.org/all/#/builders/90  Petr Viktorin, Victor Stinner
x86_64-unknownlinux-gnu glibc, clang
https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P.
Smith
=== ==
== 


Tier 3
--

- Must have a reliable buildbot.
- At least **one** core developer is signed up to support the platform.
- No response SLA to failures.
- Failures on these platforms do **not** block a release.

=== ==
== 
Target Triple   Notes  Buildbot
  Contacts
=== ==
== 
aarch64-pc-windows-msvc
https://buildbot.python.org/all/#/builders/729 Steve Dower
powerpcle-unknown-linux-gnu glibc, clang
https://buildbot.python.org/all/#/builders/435 Victor Stinner
x86_64-unknown-freebsd  BSD libc, clang
https://buildbot.python.org/all/#/builders/172 Victor Stinner
===

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Brett Cannon]

Last chance on whether my tier 3 proposal make sense! I will take silence
as acceptance and plan to convert any current tier 2 platform with a single
core dev to tier 3 and then ask the SC to approve/reject the list of
platforms. I will also update the PEP about expectations of when things
must be considered stable before b1, else a warning goes out that a
platform risks being dropped in the RC (regardless of tier).

I will also be filling out the tiers to include the vendor, but I will be
using `unknown` instead of `*` since I haven't come across the latter
online while I come across the former regularly (e.g.
https://doc.rust-lang.org/nightly/rustc/platform-support.html).

On Fri, Apr 1, 2022 at 6:50 PM Victor Stinner  wrote:

> 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 -- 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/MHOVM2A2QTICTOIRAWWG3RIUPI4BKQKI/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/SJ5CGKY7XJ54SOAWOA4Z5AEBUP64OEVS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Brett Cannon]

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/python-...@python.org/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
- 

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

I will give everyone another week, so until Friday, April 8th, to submit
review changes to https://github.com/python/peps/pull/2442/ . Below is the
list of platforms with stable buildbots that are lacking two core devs
willing to be on the hook for helping support the platforms.

   1. aarch64-windows-msvc (Steve is already listed)
   2. powerpcle-linux-gnu glibc, clang
   3. s390x-linux-gnu glibc, gcc
   4. s390x-linux-gnu glibc, clang
   5. x86_64-linux-gnu glibc, clang (Victor is already listed)
   6. x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)


On Fri, Mar 25, 2022 at 12:32 PM Brett Cannon  wrote:

> Thanks to Petr, and Victor, the platforms that are still looking for a
> total of two maintainers over at
> https://github.com/python/peps/pull/2442/files are:
>
>1. arch64-apple-darwin clang
>2. aarch64-linux-gnu glibc, clang (Victor is already listed)
>3. aarch64-windows-msvc
>4. powerpcle-linux-gnu glibc, clang
>5. s390x-linux-gnu glibc, gcc
>6. s390x-linux-gnu glibc, clang
>7. x86_64-linux-gnu glibc, clang (Victor is already listed)
>8. x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)
>
>
> On Thu, Mar 24, 2022 at 12:37 PM Brett Cannon  wrote:
>
>> Based on the positive feedback that I've gotten on this and the only
>> other suggestion was maybe bringing back tier 3 to represent, "being
>> actively worked on" support (which i think we can add later if we feel it's
>> worth it), I'm ready to ask folks to please start sending review
>> suggestions on https://github.com/python/peps/pull/2442 to add yourself
>> as supporting a platform (see
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
>> if you don't know what I mean by "review suggestion").
>>
>> I believe at least Victor is currently out at the moment, so I'm not
>> planning to rush this out and start removing platforms that lack two people
>> and merging this PR, but I also don't want to put it off either. As a
>> reminder, the platforms looking for declared support as a tier 2 platform
>> are:
>>
>>
>>1. arch64-apple-darwin clang
>>2. aarch64-linux-gnu glibc, gcc
>>3. aarch64-linux-gnu glibc, clang
>>4. aarch64-windows-msvc
>>5. powerpcle-linux-gnu glibc, gcc
>>6. powerpcle-linux-gnu glibc, clang
>>7. s390x-linux-gnu glibc, gcc
>>8. s390x-linux-gnu glibc, clang
>>9. x86_64-linux-gnu glibc, clang
>>10. x86_64-unknown-freebsd BSD libc, cc
>>
>>
>> Tier 1 is taken care of:
>>
>>1. i686-windows-msvc
>>2. x86_64-windows-msvc
>>3. x86_64-apple-darwin BSD libc, clang
>>4. x86_64-linux-gnu glibc, gcc
>>
>>
>> On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon  wrote:
>>
>>> After considering everyone's feedback, here are my proposed explanations
>>> for the tiers.
>>>
>>> Tier 1
>>> --
>>>
>>> - `CI 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,
>>>   and thus ``main``, working.
>>> - Promotion to this tier requires team consensus/SC approval.
>>>
>>> Tier 2
>>> --
>>>
>>> - Must have a reliable buildbot.
>>> - At least **two** core developers are signed up to support the platform.
>>> - Changes which break any of these platforms are to be fixed or
>>>   reverted within 24 hours.
>>> - Failures on these platforms block a release.
>>> - Promotion to this tier requires consensus/SC approval.
>>>
>>> All other platforms
>>> ---
>>>
>>> Support for a platform may be partial within the code base, such as
>>> from active development around platform support or accidentally.
>>> 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.
>>>
>>> Platforms not listed here may be supported by the wider Python
>>> community in some way. If your desired platform is not listed above,
>>> please perform a search online to see if someone is already providing
>&

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Tue, Mar 29, 2022 at 12:40 AM Anthony Baxter 
wrote:

> I wonder if putting this into a PEP might be a little heavyweight in terms
> of making adjustments to the platform triples and their priorities? I
> perhaps think something that's a look aside table with a defined policy of
> how to move various triples up and down might work better?
>

If the SC is ultimately going to be the arbiter of consensus on the status
of a platform, then a PEP is no less heavyweight than some other process.
Plus I don't see this list fluctuating regularly, so I don't think this is
any worse than e.g. the devguide.

-Brett


>
> On Fri, 11 Mar 2022, 10:36 am Brett Cannon,  wrote:
>
>> I brought this up on python-dev at
>> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
>> , and the feedback seemed supportive. As such, I am bringing a draft of
>> what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
>> for people to help me fill in to see how this will look overall.
>>
>> For any platform(s) you support, please reply with any relevant details
>> that should be added to the relevant tables below. Once I have these
>> details I will loop back with the proposed update to PEP 11 and make sure
>> everyone is still on board with the proposal.
>>
>> =
>> Tiers
>> =
>>
>> 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.
>>
>> === =
>> Target Triple   Notes
>> === =
>> i686-windows-msvc
>> x86_64-windows-msvc
>> x86_64-apple-darwin macOS 11
>> x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
>> === =
>>
>> .. [ubuntu-20_01]
>> https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4
>>
>>
>> Tier 2
>> ==
>>
>> - Must have a stable buildbot.
>> - At least **two** core developers are signed up to support the platform.
>> - Changes which break any of these platforms are to be reverted within 24
>> hours.
>> - Failures of these platforms block a release.
>> - Promotion of this tier requires consensus/SC approval.
>>
>> == ==
>> == 
>> Target Triple  Notes  Buildbot
>> Contacts
>> == ==
>> == 
>> aarch64-apple-darwin   XXX
>> https://buildbot.python.org/all/#/builders/725 XXX
>> aarch64-linux-gnu  glibc XXX [fedora-stable]_
>> https://buildbot.python.org/all/#/builders/125 XXX
>>glibc 2.28 [RHEL8]_
>> https://buildbot.python.org/all/#/builders/529 XXX
>> aarch64-windows-msvc   XXX
>> https://buildbot.python.org/all/#/builders/729 XXX
>> powerpc64-linux-gnuglibc XXX
>> https://buildbot.python.org/all/#/builders/237 XXX
>> powerpcle-linux-gnuglibc XXX
>> https://buildbot.python.org/all/#/builders/90  XXX
>> s309x-linux-gnuglibc XXX
>> https://buildbot.python.org/all/#/builders/223 XXX
>>glibc 2.28 [RHEL8]_
>> https://buildbot.python.org/all/#/builders/509 XXX
>>glibc 2.17 [RHEL7]_
>> https://buildbot.python.org/all/#/builders/179 XXX
>> x86_64-linux-gnu   glibc 2.17 [RHEL7]_
>> https://buildbot.python.org/all/#/builders/15  XXX
>> x86_64-unknown-freebsd XXX
>> https://buildbot.python.org/all/#/builders/172 XXX
>> == ==
>> == 
>>
>> .. [fedora-stable] XXX
>> .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8
>> .. [RHEL7]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc
>>
>>
>> Tier 3
>> ==
>>
>> - Must have a stable buildbot.
>> - Code may be checked into ``main`` for the platform.
>> - At least **one** core developer is signed up to support the pl

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Mon, Mar 28, 2022 at 7:09 AM Petr Viktorin  wrote:

> On Fri, Mar 25, 2022 at 8:32 PM Brett Cannon  wrote:
> >
> > Thanks to Petr, and Victor, the platforms that are still looking for a
> total of two maintainers over at
> https://github.com/python/peps/pull/2442/files are:
> >
> > arch64-apple-darwin clang
> > aarch64-linux-gnu glibc, clang (Victor is already listed)
> > aarch64-windows-msvc
> > powerpcle-linux-gnu glibc, clang
> > s390x-linux-gnu glibc, gcc
> > s390x-linux-gnu glibc, clang
>
> FWIW, I'm not listing myself for s390x. While fixing Python for
> mainframes is part of my job at Red Hat, I don't have immediate access
> to such machines and can't promise timely fixes.
> When I (or Victor or someone else) comes up with a fix, we'll of
> course want to contribute it to CPython, but I think Tier 3 is fine
> for that. Usually these fixes *make Python conform better to the C
> standard*, e.g. avoiding endianness/bit-pattern assumptions. I assume
> such fixes should be welcome regardless of platform. But, if we don't
> have a big-endian arch in the 2 tiers, endian-specific code does
> “cause a maintenance burden or obstruct general improvements”. Same
> for e.g. code that relies on “common” implementation details in malloc
> or something like that.
>
> Should the PEP explicitly say that fixing deviations from standard C
> is welcome, even if they don't manifest on the tiered arches?
>

I don't think so. That's simply a compatibility thing that we have always
done regardless of platforms. It's basic code health to adhere to the C
standard for us.
___
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/7XXWCY2RB5W3M5SG256SQZBPMTNZANQO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Sat, Mar 26, 2022 at 10:11 AM Victor Stinner  wrote:

> On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon  wrote:
> >
> > On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner 
> 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.
>
> Oh ok.
>
> 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
> regression.
>
> --
>
> 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
> revert.
>

We can talk about it, but I personally wait until the macOS runs complete.
I also hope that once merge queues
<https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/using-a-merge-queue>
go public (or we ask to get into the private beta) that it will help with
any availability issues we have with macOS.
___
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/BMFPMNSDDYMB3YEUXE6ZAPPHOGGDRNYB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 25, 2022 at 1:18 PM Ned Deily  wrote:

> On Mar 25, 2022, at 15:32, Brett Cannon  wrote:
> > Thanks to Petr, and Victor, the platforms that are still looking for a
> total of two maintainers over at
> https://github.com/python/peps/pull/2442/files are:
> >   • arch64-apple-darwin clang [...]
>
> I added this comment to the PR:
>
> If x86_64-apple-darwin is a Tier 1 platform, then this must be as well.


We realistically can't as we simply don't have the CI for
arch64-apple-darwin based on the definition of tier 1. Otherwise we would
all have to run every PR against the buildbot fleet just to test against
Apple Silicon.



> As of today, nearly all Macs being manufactured by Apple are of this
> architecture (i.e. Apple Silicon) and Apple has made clear that the few
> remaining legacy Intel-based Macs still being offered will be replaced in
> the near future (likely by the end of 2022). So, eventually
> x86_64-apple-darwin will fade in importance as older Macs are retired but
> that will take many years.
>

Yep, and my hope is we will have CI that can run on Apple Silicon at some
point which will let us promote the platform, but until then it's not at
the same level as the x64 support.
___
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/TBDN2QQQ7UEMKNA4INCCGUVGIDFT5GYS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

Thanks to Petr, and Victor, the platforms that are still looking for a
total of two maintainers over at
https://github.com/python/peps/pull/2442/files are:

   1. arch64-apple-darwin clang
   2. aarch64-linux-gnu glibc, clang (Victor is already listed)
   3. aarch64-windows-msvc
   4. powerpcle-linux-gnu glibc, clang
   5. s390x-linux-gnu glibc, gcc
   6. s390x-linux-gnu glibc, clang
   7. x86_64-linux-gnu glibc, clang (Victor is already listed)
   8. x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)


On Thu, Mar 24, 2022 at 12:37 PM Brett Cannon  wrote:

> Based on the positive feedback that I've gotten on this and the only other
> suggestion was maybe bringing back tier 3 to represent, "being actively
> worked on" support (which i think we can add later if we feel it's worth
> it), I'm ready to ask folks to please start sending review suggestions on
> https://github.com/python/peps/pull/2442 to add yourself as supporting a
> platform (see
> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
> if you don't know what I mean by "review suggestion").
>
> I believe at least Victor is currently out at the moment, so I'm not
> planning to rush this out and start removing platforms that lack two people
> and merging this PR, but I also don't want to put it off either. As a
> reminder, the platforms looking for declared support as a tier 2 platform
> are:
>
>
>1. arch64-apple-darwin clang
>2. aarch64-linux-gnu glibc, gcc
>3. aarch64-linux-gnu glibc, clang
>4. aarch64-windows-msvc
>5. powerpcle-linux-gnu glibc, gcc
>6. powerpcle-linux-gnu glibc, clang
>7. s390x-linux-gnu glibc, gcc
>8. s390x-linux-gnu glibc, clang
>9. x86_64-linux-gnu glibc, clang
>10. x86_64-unknown-freebsd BSD libc, cc
>
>
> Tier 1 is taken care of:
>
>1. i686-windows-msvc
>2. x86_64-windows-msvc
>    3. x86_64-apple-darwin BSD libc, clang
>4. x86_64-linux-gnu glibc, gcc
>
>
> On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon  wrote:
>
>> After considering everyone's feedback, here are my proposed explanations
>> for the tiers.
>>
>> Tier 1
>> --
>>
>> - `CI 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,
>>   and thus ``main``, working.
>> - Promotion to this tier requires team consensus/SC approval.
>>
>> Tier 2
>> --
>>
>> - Must have a reliable buildbot.
>> - At least **two** core developers are signed up to support the platform.
>> - Changes which break any of these platforms are to be fixed or
>>   reverted within 24 hours.
>> - Failures on these platforms block a release.
>> - Promotion to this tier requires consensus/SC approval.
>>
>> All other platforms
>> ---
>>
>> Support for a platform may be partial within the code base, such as
>> from active development around platform support or accidentally.
>> 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.
>>
>> Platforms not listed here may be supported by the wider Python
>> community in some way. If your desired platform is not listed above,
>> please perform a search online to see if someone is already providing
>> support in some form.
>>
>>
>> I have a draft PR up at https://github.com/python/peps/pull/2442 which
>> can be previewed at
>> https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes
>> reading the table much easier). I made the platforms list the platform
>> triple, libc, and compiler **without** version details.
>>
>> Once I have buy-in for the above I will explicitly ask folks to send
>> review comments to that PR to add themselves to the platforms they are
>> willing to support, and then drop any which lack two core developers
>> (warnings to the Fedora/RH folks: most of those platforms are listed are
>> using Fedora buildbots, so it might be up  to you ). I did drop
>> powerpc-linux-gnu from the list as that buildbot has not successfully built
>> in quite some time (powerpcle seems fine).
>>
>> On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith  wrote:
>>
>>>
>

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner  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.

If you still want a point of contact for those platforms then we can talk
about that, but I wouldn't expect the listed folks to be as critical on
those platforms to keep things functioning like they are for a tier 2 being
supported by a buildbot post-merge.

Or put another way, tier 1 platforms are so critical we can't be expected
to be dropped if someone isn't being responsive to questions, unlike tier 2
where we would probably drop a platform if folks weren't responsive enough.


> IMO you must also put two names in front of each
> platform. Otherwise, nobody will fix them when it will be broken, and
> the best that we will be able to do is to just revert the change
> breaking the CI which prevents adding new features just because nobody
> wants to fix the CI.
>
> Sometimes, a broken CI is unrelated to a Python change. Things break,
> *all the time*, for many various reasons including vacuum cleaners
> (*)!
>

But tier 1 is the CI we run on PRs, not in the Buildbot fleet.


>
> (*)
> https://mail.python.org/archives/list/python-buildb...@python.org/message/27OMCAPT6TCZUKAXBTL3X3PCKLXCMS5J/
>
> Victor
>
___
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/UTNDM3V4VM7QCYFISX4XBSJ3MP7CO2P6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

Based on the positive feedback that I've gotten on this and the only other
suggestion was maybe bringing back tier 3 to represent, "being actively
worked on" support (which i think we can add later if we feel it's worth
it), I'm ready to ask folks to please start sending review suggestions on
https://github.com/python/peps/pull/2442 to add yourself as supporting a
platform (see
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
if you don't know what I mean by "review suggestion").

I believe at least Victor is currently out at the moment, so I'm not
planning to rush this out and start removing platforms that lack two people
and merging this PR, but I also don't want to put it off either. As a
reminder, the platforms looking for declared support as a tier 2 platform
are:


   1. arch64-apple-darwin clang
   2. aarch64-linux-gnu glibc, gcc
   3. aarch64-linux-gnu glibc, clang
   4. aarch64-windows-msvc
   5. powerpcle-linux-gnu glibc, gcc
   6. powerpcle-linux-gnu glibc, clang
   7. s390x-linux-gnu glibc, gcc
   8. s390x-linux-gnu glibc, clang
   9. x86_64-linux-gnu glibc, clang
   10. x86_64-unknown-freebsd BSD libc, cc


Tier 1 is taken care of:

   1. i686-windows-msvc
   2. x86_64-windows-msvc
   3. x86_64-apple-darwin BSD libc, clang
   4. x86_64-linux-gnu glibc, gcc


On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon  wrote:

> After considering everyone's feedback, here are my proposed explanations
> for the tiers.
>
> Tier 1
> --
>
> - `CI 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,
>   and thus ``main``, working.
> - Promotion to this tier requires team consensus/SC approval.
>
> Tier 2
> --
>
> - Must have a reliable buildbot.
> - At least **two** core developers are signed up to support the platform.
> - Changes which break any of these platforms are to be fixed or
>   reverted within 24 hours.
> - Failures on these platforms block a release.
> - Promotion to this tier requires consensus/SC approval.
>
> All other platforms
> ---
>
> Support for a platform may be partial within the code base, such as
> from active development around platform support or accidentally.
> 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.
>
> Platforms not listed here may be supported by the wider Python
> community in some way. If your desired platform is not listed above,
> please perform a search online to see if someone is already providing
> support in some form.
>
>
> I have a draft PR up at https://github.com/python/peps/pull/2442 which
> can be previewed at
> https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes reading
> the table much easier). I made the platforms list the platform triple,
> libc, and compiler **without** version details.
>
> Once I have buy-in for the above I will explicitly ask folks to send
> review comments to that PR to add themselves to the platforms they are
> willing to support, and then drop any which lack two core developers
> (warnings to the Fedora/RH folks: most of those platforms are listed are
> using Fedora buildbots, so it might be up  to you ). I did drop
> powerpc-linux-gnu from the list as that buildbot has not successfully built
> in quite some time (powerpcle seems fine).
>
> On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith  wrote:
>
>>
>>
>> On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg 
>> wrote:
>>
>>> On 14.03.2022 19:34, Brett Cannon wrote:
>>> > Greg proposed something like "Code changes to support platforms beyond
>>> tier1 or
>>> > tier2 may be rejected, broken, or removed from the CPython codebase
>>> without
>>> > notice if they cause a maintenance burden for tier1&2 or obstruct
>>> general
>>> > improvements." and drop the concept of tier 3. Does that work for you?
>>>
>>> Almost :-) I don't understand the "without notice". I guess Greg
>>> meant "without deprecation process". Removal of support code should
>>> be discussed on a ticket and then listed in PEP 11 and
>>> mentioned in the NEWS file, as usual.
>>>
>>
>> I guess I was trying to convey that we may not even have a way to kno

[python-committers] Re: Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")

[Brett Cannon]

On Wed, Mar 23, 2022 at 2:23 AM Paul Moore  wrote:

> On Tue, 22 Mar 2022 at 23:27, Brett Cannon  wrote:
>
> > Update PEP 2 to say a PEP is necessary to add a module to the stdlib
> > Update PEP 4 to say that a PEP is necessary to deprecate/remove a module
> > Mark PEP 411 as obsolete and thus dropping the idea of provisional
> modules
>
> These all seem reasonable to me.
>
> There's an implication for the Packaging community in that we have
> used "Provisional" status for PEPs (specifications). But personally,
> I'm fine with dropping that option - I'm on record saying that I don't
> like provisional status for packaging standards and won't use it in
> future.
>

This doesn't affect provisional *PEPs*, only *modules*; provisional PEP
acceptances are covered under a different PEP (probably PEP 1).

-Brett


>
> Assuming this proposal gets approved, I will link to the PEP 411
> change on the relevant packaging thread, and get the packaging process
> docs updated to match.
>
> Paul
>
___
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/XEEZDGNER7IICHHGLRIZ7GBHTLVHNNAH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")

[Brett Cannon]

I had kicked off a discussion a while back at
https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681
about how to manage the stdlib (this has nothing to with *what* the stdlib
is and thus what belongs in it). It finally bubbled up in the SC agenda and
after discussing things we have three proposals:

   1. Update PEP 2 to say a PEP is necessary to add a module to the stdlib
   2. Update PEP 4 to say that a PEP is necessary to deprecate/remove a
   module
   3. Mark PEP 411 as obsolete and thus dropping the idea of provisional
   modules

The PEP requirements are because the stdlib is important to manage
appropriately and since it's a shared resource it should be something we
all discuss. The PEP process seems like a good mechanism for both keeping
what we bring in under control while also making sure people don't break
people's code needlessly with removals.

The dropping of the concept of provisional modules is from simply having
not seen any true benefit that could have been had in other ways (e.g.
typing, asyncio, importlib.metadata). In pretty much all cases the APIs
could have evolved publicly first and then been brought into the stdlib
once stable (if at all), so the concept of "provisional" just doesn't seem
worth keeping around.

We wanted to see if there was consensus around any of these ideas, hence
this email. 
___
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/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

After considering everyone's feedback, here are my proposed explanations
for the tiers.

Tier 1
--

- `CI 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,
  and thus ``main``, working.
- Promotion to this tier requires team consensus/SC approval.

Tier 2
--

- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be fixed or
  reverted within 24 hours.
- Failures on these platforms block a release.
- Promotion to this tier requires consensus/SC approval.

All other platforms
---

Support for a platform may be partial within the code base, such as
from active development around platform support or accidentally.
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.

Platforms not listed here may be supported by the wider Python
community in some way. If your desired platform is not listed above,
please perform a search online to see if someone is already providing
support in some form.


I have a draft PR up at https://github.com/python/peps/pull/2442 which can
be previewed at https://pep-previews--2442.org.readthedocs.build/pep-0011/
(makes reading the table much easier). I made the platforms list the
platform triple, libc, and compiler **without** version details.

Once I have buy-in for the above I will explicitly ask folks to send review
comments to that PR to add themselves to the platforms they are willing to
support, and then drop any which lack two core developers (warnings to the
Fedora/RH folks: most of those platforms are listed are using Fedora
buildbots, so it might be up  to you ). I did drop powerpc-linux-gnu from
the list as that buildbot has not successfully built in quite some time
(powerpcle seems fine).

On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith  wrote:

>
>
> On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg 
> wrote:
>
>> On 14.03.2022 19:34, Brett Cannon wrote:
>> > Greg proposed something like "Code changes to support platforms beyond
>> tier1 or
>> > tier2 may be rejected, broken, or removed from the CPython codebase
>> without
>> > notice if they cause a maintenance burden for tier1&2 or obstruct
>> general
>> > improvements." and drop the concept of tier 3. Does that work for you?
>>
>> Almost :-) I don't understand the "without notice". I guess Greg
>> meant "without deprecation process". Removal of support code should
>> be discussed on a ticket and then listed in PEP 11 and
>> mentioned in the NEWS file, as usual.
>>
>
> I guess I was trying to convey that we may not even have a way to know
> that we're breaking something on a non-tier1/2 platform anyways so "without
> notice" was just me trying to set people's expectations.  We don't go out
> of our way to _try_ and break things most of the time.  "without a
> deprecation process" is also reasonable wording.  Feel free to adopt those
> words.
>
> Ideally we try to have discussion somewhere relevant when we _know_ we'd
> intentionally be removing support for something (for example of why: See
> the debacle that happened when dropping Solaris support was proposed).
>
> -gps
>
>
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Experts (#1, Mar 14 2022)
>> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
>> >>> Python Product Development ...https://consulting.egenix.com/
>> 
>>
>> ::: We implement business ideas - efficiently in both time and costs :::
>>
>>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>Registered at Amtsgericht Duesseldorf: HRB 46611
>>https://www.egenix.com/company/contact/
>>  https://www.malemburg.com/
>>
>> ___
>> 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.o

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Mon, Mar 14, 2022 at 12:59 PM Christian Heimes 
wrote:

> On 14/03/2022 19.37, Brett Cannon wrote:
> >
> >
> > On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner  > <mailto:vstin...@python.org>> wrote:
> >
> > Hi Brett,
> >
> > You can put my name as Contact of all Fedora and RHEL platforms.
> >
> > Note: Fedora "Rawhide" is the rolling release and it's common that
> > these buildbots are broken by kernel, compiler or glibc updates,
> > rather than actual Python regressions. Time to time, it detects real
> > Python regressions. Tier 2 should only target Fedora *Stable* (which
> > is the case ;-)).
> >
> >  > glibc XXX [fedora-stable]
> >
> > Mentioning that Fedora uses glibc is nice, but I don't think that
> it's
> > worth it to mention the glibc version. Fedora is released every 6
> > months and the glibc version is updated at each Fedora release.
> >
> >
> >
> > Christian had suggested/asked for that. So are people okay dropping the
> > glibc version and instead documenting that it's testing glibc instead of
> > e.g. musl?
>
> Looks like I was not communicating my intention clearly. I don't want to
> list libc ABI and Kernel ABI of every targeted distro. Instead I would
> like to include only the glibc version of the oldest manylinux wheel
> standard that is supported by PyPI.
>

That concept doesn't exist anymore thanks to perennial manylinux support:
https://peps.python.org/pep-0600/ .


>
> glibc has a strong forward compatibility guarantee. If something works
> with glibc 2.17, then it will also work with 2.34. A minimum glibc
> version sets the minimum feature set that we can rely on. If we say that
> Python is tested with glibc 2.17 and Kernel ABI 3.10 (CentOS 7), then we
> set CentOS 7 a baseline for users that also covers Debian Oldstable.
>
> glibc and Kernel ABI are relevant for some features like getrandom()
> syscall, memfd_create, and similar.
>

Since the glibc version support is now embedded as part of the tag for
wheels on Linux, I don't think we can really specify a minimum anymore. In
that case it probably comes down to simply saying a platform using glibc
for the libc implementation is enough.

-Brett
___
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/APQ5FUVKG2FERFS3ILVAMGQ7KGNVDPJF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner  wrote:

> Hi Brett,
>
> You can put my name as Contact of all Fedora and RHEL platforms.
>
> Note: Fedora "Rawhide" is the rolling release and it's common that
> these buildbots are broken by kernel, compiler or glibc updates,
> rather than actual Python regressions. Time to time, it detects real
> Python regressions. Tier 2 should only target Fedora *Stable* (which
> is the case ;-)).
>
> > glibc XXX [fedora-stable]
>
> Mentioning that Fedora uses glibc is nice, but I don't think that it's
> worth it to mention the glibc version. Fedora is released every 6
> months and the glibc version is updated at each Fedora release.
>


Christian had suggested/asked for that. So are people okay dropping the
glibc version and instead documenting that it's testing glibc instead of
e.g. musl?

-Brett


>
> > x86_64-unknown-freebsd XXX
> https://buildbot.python.org/all/#/builders/172 XXX
>
> You can put my name as Contact for the FreeBSD buildbot.
>
> I don't *actively* support FreeBSD, but last years, I did "best
> effort" support: add some FreeBSD features sometimes, adapt Python for
> new FreeBSD changes, fix regressions specific to FreeBSD, investigate
> unstable tests which only fail on FreeBSD, etc.
>
> You can mention that FreeBSD now uses the "clang" C compiler, since
> most Linux distributions (ex: RHEL) use GCC. It's a significant
> difference.
>

Do we want to mention compilers in this? And is it just at the extent of
which compiler but w/o a version number?
___
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/XPPZWKO4HDHBXY7TBCP3YGRWYISYKBPL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Sat, Mar 12, 2022 at 5:29 AM Marc-Andre Lemburg  wrote:

> On 11.03.2022 19:26, Brett Cannon wrote:
>
>
>
> On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg  wrote:
>
>> I think the list is missing some important platforms which we do
>> support (looking at configure):
>>
>> * Linux on 32-bit ARM platforms, e.g. for Raspberry Pis
>> * Linux on Android
>> * AIX
>> * Cygwin
>> * NetBSD/OpenBSD
>> * musl instead of glibc for Linux, e.g. for Alpine images
>>
>
> I went off of what we have stable buildbots for. If we want to either
> loosen the tier 3 requirement for a Buildbot or introduce a historical tier
> 4 we can. But, for instance, do any of us if AIX support actually works
> right now?
>
> I've not built on AIX in a longer while, but the AIX Toolbox lists Python
> 3.9 as a package, so at least that version builds on AIX:
>
>
> https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads-alpha#P
> http://www.aixtools.net/index.php/python3
>
> https://www.ibm.com/support/pages/tips-installing-python-or-other-aix-toolbox-open-source-software
>
> In general, I believe we should add a 4th tier for platforms supported
>> by interested parties outside the core team. Those would be supported on
>> a best effort basis by the parties and we'd point to the teams for
>> support. Some of the above platforms would likely have to go into
>> this tier.
>>
>
> My worry with that is having to try and keep that information up-to-date.
> Plus I would prefer to not have a PEP listing platforms where the status of
> the support is 路.
>
> If people start to rely on PEP 11 for determining whether Python has
> support for a certain platform or not, I believe it's important to list
> such 3rd party efforts in the PEP as well. Otherwise, we'd be cutting off
> those efforts from being taken seriously and put off people who want to
> invest time into bringing Python to their platform.
>
> My preference would be to not have PEP 11 limit support we add to the core
> for platforms which the core team does not support directly. It's fine to
> list platforms we actively support, but not to outrule adding support for
> platforms which are community supported.
>
> Easiest would be to drop the line at the end of the proposed change.
>

Greg proposed something like "Code changes to support platforms beyond
tier1 or tier2 may be rejected, broken, or removed from the CPython
codebase without notice if they cause a maintenance burden for tier1&2 or
obstruct general improvements." and drop the concept of tier 3. Does that
work for you?

-Brett


>
> It would also be nice to add a column to the table which shows
>> the platforms for which binaries are built during the release and
>> which are source only. At the moment, only Windows and
>> macOS platforms have official binaries.
>>
>
> I was actually explicitly asked by someone who is part of doing releases
> *not* to list installers as they would prefer they not be viewed as
> required to exist.
>
> Fair enough.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Mar 12 2022)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
>
___
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/MPHJYKIUXL4OYWUTVGKHYY7URFG7QNIK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 12:37 PM Gregory P. Smith  wrote:

>
> On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon  wrote:
>
>>
>> On Fri, Mar 11, 2022 at 9:16 AM Paul Moore  wrote:
>>
>>> On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg  wrote:
>>> >
>>> > On 11.03.2022 17:42, Zachary Ware wrote:
>>> > >
>>> > > - Only code which either supports a higher-tier platform or is a
>>> general improvement may be checked in.
>>> >
>>> > My understanding of that sentence is: PRs which target platforms
>>> > not listed in PEP 11 may not be checked in.
>>> >
>>> > IMO, it doesn't make sense to prohibit support code in the
>>> > code base, if there is community interest in this. By dropping
>>> > that line, we wouldn't have a problem and also don't
>>> > need to list platforms in a tier 4 section, since it's still
>>> > possible to add support in the main code base, without having
>>> > a core dev maintain it.
>>>
>>> I agree, the simplest solution here seems to be just to not include
>>> that line. We can still push back on PRs for unsupported platforms if
>>> we want, we just won't have a policy that *requires* us to do so.
>>>
>>> If it turns out that leaving it to core devs' judgement is a problem,
>>> we can agree a policy with some concrete examples to inform us.
>>>
>>
>> It's already a guideline we hold, but I'm fine with weakening the
>> language to make more of a cautious warning to only merge paltform-specific
>> code if you have good reasons to.
>>
>
> I wouldn't word it as a prohibition.  Just get rid of the line entirely.
>
> I'd also get rid of Tier 3.  It isn't useful - that tier doesn't *block*
> anything so we shouldn't be maintaining a documented list of things that
> come and go at that level.  That's pure makework and conveys nothing that
> the existence of a buildbot does not already do.
>
> If you want a line to include about code supporting non tier1/2 platforms,
> I'd word it as:
>
> "Code changes to support platforms beyond tier1 or tier2 may be rejected,
> broken, or removed from the CPython codebase without notice if they cause a
> maintenance burden for tier1&2 or obstruct general improvements."
>

I'm fine with that. It still lets those of us working on WebAssembly to
upstream stuff but we can't claim full support until we get a Buildbot
which seems fair.


>
> This simplifies the story and better reflects reality.  Things listed in a
> tier are meaningful without 3 because they block releases rather than
> needing to know that tier 3 is a no-op.
>
> The buildbot concept of "stable" is arbitrary.  It is a configuration
> tag.  There is no strict authority to gatekeep and curate it.  If a release
> manager or steering council said to remove the "stable" tag from a buildbot
> they'd likely be listened to. Otherwise it's collectively up to whomever
> maintains the bot configs and approves the config PRs.  Stability of a
> machine setup for reliability purposes is unrelated to importance.
>
> Ex: I don't tag my raspbian bot as "stable" because it lives at home where
> I provide a SLO of nothing.  It has nothing to do with importance.  It is
> clearly a more important platform than wasm today.
>

I think it's more about making sure if we are going to let a Buildbot run
block a release we want to make sure that it's reliable enough to use for
that purpose. I think using the term "stable" is unfortunately overloaded,
so I won't plan to use it.

-Brett


>
> > .. [ubuntu-20_01]
>
> Call this link ubuntu-20_04 to avoid confusion.  Ubuntu versions are
> always YY.04 and YY.10 unless they miss their planned release window [rare].
>
> -gps
>
>
___
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/IPJPO4LBBCGICDFLHFR6WTEG3AT7J3TA/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 9:16 AM Paul Moore  wrote:

> On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg  wrote:
> >
> > On 11.03.2022 17:42, Zachary Ware wrote:
> > >
> > > - Only code which either supports a higher-tier platform or is a
> general improvement may be checked in.
> >
> > My understanding of that sentence is: PRs which target platforms
> > not listed in PEP 11 may not be checked in.
> >
> > IMO, it doesn't make sense to prohibit support code in the
> > code base, if there is community interest in this. By dropping
> > that line, we wouldn't have a problem and also don't
> > need to list platforms in a tier 4 section, since it's still
> > possible to add support in the main code base, without having
> > a core dev maintain it.
>
> I agree, the simplest solution here seems to be just to not include
> that line. We can still push back on PRs for unsupported platforms if
> we want, we just won't have a policy that *requires* us to do so.
>
> If it turns out that leaving it to core devs' judgement is a problem,
> we can agree a policy with some concrete examples to inform us.
>

It's already a guideline we hold, but I'm fine with weakening the language
to make more of a cautious warning to only merge paltform-specific code if
you have good reasons to.
___
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/5DRDOK6M2D3JADJKJT5BENOJ26GYGBUN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 8:43 AM Zachary Ware  wrote:

> On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg  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  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/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 1:38 AM Christian Heimes 
wrote:

> On 11/03/2022 00.35, Brett Cannon wrote:
> > I brought this up on python-dev at
> >
> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> > <
> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/>
>
> > , and the feedback seemed supportive. As such, I am bringing a draft of
> > what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
> > for people to help me fill in to see how this will look overall.
> >
> > For any platform(s) you support, please reply with any relevant details
> > that should be added to the relevant tables below. Once I have these
> > details I will loop back with the proposed update to PEP 11 and make
> > sure everyone is still on board with the proposal.
>
>
> A few remarks:
>
> autoconf, GCC, and Debian call it "Target Triplet". Clang and Rust use
> "Target Triple". Should we stick with the clang name or use the GCC name?
>
> Target triplets are machine-vendor-os. They come in short, normalized
> form and in long, extended form. The normalized form often omits the
> vendor field. Your document has both long and short forms.
> "wasm32-unknown-emscripten" is extended form for "wasm32-emscripten",
> while "x86_64-windows-msvc" is the short form of
> "x86_64-pc-windows-msvc". I recommend to stick to one convention.
>

Whatever you all tell me.  I did the best I could on what the Rust tiers
listed and what I know.


>
> By the way config.guess script and gcc can dump the current triplet. The
> config.sub script can be used to normalize and validate a triplet (does
> not work for MSVC). The output of config.guess is more specific than the
> gcc machine info. Here is a dump from my RPi:
>
> $ ./config.guess
> armv7l-unknown-linux-gnueabihf
> $ gcc -dumpmachine
> arm-linux-gnueabih
> $ ./config.sub arm-linux-gnueabihf
> arm-unknown-linux-gnueabihf
>
>
> > = ==
> > == 
> > Target Triple Notes  Buildbot
> >      Contacts
> > = ==
> > ====== 
> > wasm32-unknown-emscripten XXXXXX
> > Brett Cannon, Christian Heimes
> > wasm32-unknown-wasi   XXXXXX
> > Brett Cannon, Christian Heimes
> > = ==
> > == 
>
> It's a bit premature to add wasm32-wasi. Python doesn't even compile on
> WASI yet.
>




>
> Christian
>
___
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/YXEN4GW3GTJUHULIOY45PHSKGNYHAM4E/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 1:26 AM Petr Viktorin  wrote:

> On 11. 03. 22 0:35, Brett Cannon wrote:
> > I brought this up on python-dev at
> >
> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> > <
> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/>
>
> > , and the feedback seemed supportive. As such, I am bringing a draft of
> > what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
> > for people to help me fill in to see how this will look overall.
> >
> > For any platform(s) you support, please reply with any relevant details
> > that should be added to the relevant tables below. Once I have these
> > details I will loop back with the proposed update to PEP 11 and make
> > sure everyone is still on board with the proposal.
> >
> > =
> > Tiers
> > =
> >
> > Tier 1
> > ==
> >
> > - `Test suite failures
> > <
> https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted
> > <
> 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.
>
> What does this mean?
> I can not merge a change if it doesn't pass macOS CI, but I don't have a
> macOS system, so I can't really diagnose and fix macOS bugs.
>

Do you merge PRs today that don't pass CI on macOS?


>
> > - Promotion of this tier requires consensus/SC approval.
> >
> > === =
> > Target Triple   Notes
> > === =
> > i686-windows-msvc
>
> What's the supported version of Windows?
>
> > x86_64-windows-msvc
> > x86_64-apple-darwin macOS 11
> > x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
>
> Would it be better to say “whatever GitHub Actions has” in the long-term
> docs, and put the specific version in the docs rather than in the PEP?
>

Perhaps; I was tempted to do that, but Christian requested the triples.


>
>
>
> [...]> All other platforms
> > ===
> >
> > - Only code which either supports a higher-tier platform or is a general
> > improvement may be checked in.
>
> I'm worried about going from this to tier 3.
> How do you get to a platform's buildbot being stable if you can't merge
> code for it?
>


You could develop code outside of the CPython repo until the platform is
ready to be supported.

Would you propose to drop the Buildbot requirement for tier 3 or introduce
a tier 4?
___
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/E43OQIOZ745MZFAZTPUJEKYMVWOUH2EI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg  wrote:

> I think the list is missing some important platforms which we do
> support (looking at configure):
>
> * Linux on 32-bit ARM platforms, e.g. for Raspberry Pis
> * Linux on Android
> * AIX
> * Cygwin
> * NetBSD/OpenBSD
> * musl instead of glibc for Linux, e.g. for Alpine images
>

I went off of what we have stable buildbots for. If we want to either
loosen the tier 3 requirement for a Buildbot or introduce a historical tier
4 we can. But, for instance, do any of us if AIX support actually works
right now?


>
> In general, I believe we should add a 4th tier for platforms supported
> by interested parties outside the core team. Those would be supported on
> a best effort basis by the parties and we'd point to the teams for
> support. Some of the above platforms would likely have to go into
> this tier.
>

My worry with that is having to try and keep that information up-to-date.
Plus I would prefer to not have a PEP listing platforms where the status of
the support is 路.


>
> It would also be nice to add a column to the table which shows
> the platforms for which binaries are built during the release and
> which are source only. At the moment, only Windows and
> macOS platforms have official binaries.
>

I was actually explicitly asked by someone who is part of doing releases
*not* to list installers as they would prefer they not be viewed as
required to exist.

-Brett


>
>
> On 11.03.2022 00:35, Brett Cannon wrote:
> > I brought this up on python-dev at
> >
> https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> > , and the feedback seemed supportive. As such, I am bringing a draft of
> what I'm
> > thinking will go into PEP 11 with a bunch of `XXX` placeholders for
> people to
> > help me fill in to see how this will look overall.
> >
> > For any platform(s) you support, please reply with any relevant details
> that
> > should be added to the relevant tables below. Once I have these details
> I will
> > loop back with the proposed update to PEP 11 and make sure everyone is
> still on
> > board with the proposal.
> >
> > =
> > Tiers
> > =
> >
> > 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.
> >
> > === =
> > Target Triple   Notes
> > === =
> > i686-windows-msvc
> > x86_64-windows-msvc
> > x86_64-apple-darwin macOS 11
> > x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
> > === =
> >
> > .. [ubuntu-20_01]
> https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4
> >
> >
> > Tier 2
> > ==
> >
> > - Must have a stable buildbot.
> > - At least **two** core developers are signed up to support the platform.
> > - Changes which break any of these platforms are to be reverted within
> 24 hours.
> > - Failures of these platforms block a release.
> > - Promotion of this tier requires consensus/SC approval.
> >
> > == ==
> > == 
> > Target Triple  Notes  Buildbot
>
> > Contacts
> > == ==
> > == 
> > aarch64-apple-darwin   XXX
> >  https://buildbot.python.org/all/#/builders/725 XXX
> > aarch64-linux-gnu  glibc XXX [fedora-stable]_
> > https://buildbot.python.org/all/#/builders/125 XXX
> >glibc 2.28 [RHEL8]_
> >  https://buildbot.python.org/all/#/builders/529 XXX
> > aarch64-windows-msvc   XXX
> >  https://buildbot.python.org/all/#/builders/729 XXX
> > powerpc64-linux-gnuglibc XXX
> >  https://buildbot.python.org/all/#/builders/237 XXX
> > powerpcle-linux-gnuglibc XXX
> >  https://buildbot.python.org/all/#/builders/90  XXX
> > s309x-linux-gnuglibc XXX
> >  https://buildbot.python.org/all/#/builders/223 XXX
> >glibc 2.28 [RHEL8]_
> >  https://buildbot.python.org/all/#/builders/509 XXX
> >  

[python-committers] Proposed tiered platform support

[Brett Cannon]

I brought this up on python-dev at
https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
, and the feedback seemed supportive. As such, I am bringing a draft of
what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
for people to help me fill in to see how this will look overall.

For any platform(s) you support, please reply with any relevant details
that should be added to the relevant tables below. Once I have these
details I will loop back with the proposed update to PEP 11 and make sure
everyone is still on board with the proposal.

=
Tiers
=

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.

=== =
Target Triple   Notes
=== =
i686-windows-msvc
x86_64-windows-msvc
x86_64-apple-darwin macOS 11
x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
=== =

.. [ubuntu-20_01] https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4


Tier 2
==

- Must have a stable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be reverted within 24
hours.
- Failures of these platforms block a release.
- Promotion of this tier requires consensus/SC approval.

== ==
== 
Target Triple  Notes  Buildbot
  Contacts
== ==
== 
aarch64-apple-darwin   XXX
https://buildbot.python.org/all/#/builders/725 XXX
aarch64-linux-gnu  glibc XXX [fedora-stable]_
https://buildbot.python.org/all/#/builders/125 XXX
   glibc 2.28 [RHEL8]_
https://buildbot.python.org/all/#/builders/529 XXX
aarch64-windows-msvc   XXX
https://buildbot.python.org/all/#/builders/729 XXX
powerpc64-linux-gnuglibc XXX
https://buildbot.python.org/all/#/builders/237 XXX
powerpcle-linux-gnuglibc XXX
https://buildbot.python.org/all/#/builders/90  XXX
s309x-linux-gnuglibc XXX
https://buildbot.python.org/all/#/builders/223 XXX
   glibc 2.28 [RHEL8]_
https://buildbot.python.org/all/#/builders/509 XXX
   glibc 2.17 [RHEL7]_
https://buildbot.python.org/all/#/builders/179 XXX
x86_64-linux-gnu   glibc 2.17 [RHEL7]_
https://buildbot.python.org/all/#/builders/15  XXX
x86_64-unknown-freebsd XXX
https://buildbot.python.org/all/#/builders/172 XXX
== ==
== 

.. [fedora-stable] XXX
.. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8
.. [RHEL7]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc


Tier 3
==

- Must have a stable buildbot.
- Code may be checked into ``main`` for the platform.
- At least **one** core developer is signed up to support the platform.
- Test failures do **not** block releases.
- Promotion to this tier is self-service.

= ==
== 
Target Triple Notes  Buildbot
Contacts
= ==
== 
wasm32-unknown-emscripten XXXXXX
     Brett Cannon, Christian Heimes
wasm32-unknown-wasi   XXXXXX
     Brett Cannon, Christian Heimes
= ==
== 


All other platforms
===

- Only code which either supports a higher-tier platform or is a general
improvement may be checked in.
___
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/K757345KX6W5ZLTWYBUXOXQTJJTL7GW5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Jelle Zijlstra to the team!

[Brett Cannon]

___
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/3W5YO6EG7K3BVWNE5OW4JGGEO2UYQFHO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Dennis Sweeney to the team!

[Brett Cannon]

___
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/PWYBGSS6RNSGKT5BQBC2DELC2TRLHNC7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Please turn on 2FA/MFA support on your GitHub account

[Brett Cannon]

In the SC meeting today we discussed requiring two-factor authentication
(aka 2FA/MFA) and came away strongly considering it (but no definitive
plans yet). But we did agree that we should send a quick email encouraging
everyone to turn on 2FA for their GitHub Accounts regardless of what we
decide to do.

GitHub's instructions can be found at
https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/accessing-github-using-two-factor-authentication
. You can use various apps on your desktop or phone as well as a physical
device to manage 2FA. And to be clear, you only need access to your 2FA
solution when you log in; it's not a day-to-day action at all (I personally
have not used my 2FA since the last time I logged into a new device for the
first time or when my GitHub account was attacked and the attackers
exhausted my password attempts for the day).

For those of you who would prefer to use a hardware device and would like
help getting one, we can make a request to the PSF to sponsor devices for
those who want them.
___
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/2UC5H7WWJZDA2K7XM5CLAZIX3KWJ2ASK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Stepping back from being the person in charge of infrastructure

[Brett Cannon]

I got @ mentioned on some bot stuff the other day on Discord and I realized
I am no longer in a good position to be considered the person to loop in on
that sort of stuff. My code contribution rate in CPython isn't high enough
right now for me to drive what our workflow should be, but I'm not a new
contributor either so I have obvious bias/blind spots over what's needed.

As such, I wanted to publicly say I shouldn't be leaned on for driving what
the bots should do, improvements to make to our workflow, etc. My
suggestion would be to look at what our current bots do, see if any of it
is outdated compared to what GitHub offers us, and then try to lean on
GitHub Actions more instead of hosting on Heroku for easier maintenance and
transparency for when things fail (as the vast majority of issues that get
brought up around the bots is that GitHub didn't send a message to Heroku,
not due to a bug).

P.S. I almost looked up how long I have been driving workflow stuff but I
realized it's past a decade from getting off of svn alone and I'm too lazy
to looks up when bugs.python.org came about. 
___
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/GB7T23XWLNKR24V5IWBADYSLFK6KWCY6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Dates for the core dev sprints

[Brett Cannon]

Based on the results of the poll on discuss.python.org, the core dev
sprints will be from October 18 - 24. Based on feedback from last year and
for simplicity reasons, the sprints will be hosted on the core dev Discord
server (link in the Inquisition category on discuss.python.org to keep it
private to core devs only; also don't forget to record your Discord
username, which is formatted as r".+#\d+", to
https://github.com/python/voters/ if you have not already).

We currently have no organizer(s) for this, so right now this will be
self-organized on the spot.  If anyone wants to volunteer to run the
sprints then please let the SC know.
___
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/657GHJ7KHOGGGRJQCJJ2D3TL2JE2DYO7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Friendly reminder to add yourself to .github/CODEOWNERS when creating new PEPs

[Brett Cannon]

For all PEPs we ask the core dev who is sponsoring/(co-)authoring to list
themselves in https://github.com/python/peps/blob/master/.github/CODEOWNERS
so you get notified when a PR comes in for the PEP.
___
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/OGKGSW3KJGLZKEVPSQW6SYDFG4KLNRA5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Ken Jin to the team!

[Brett Cannon]

___
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/VUIND4NXY74E7Y75AKLR5FVPQVSM6MJL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] You can now record your Discord username in the python/voters repo

[Brett Cannon]

Just add the `discord` key to your entry in
https://github.com/python/voters/blob/master/python-core.toml with your
username. Totally optional as always, but since we now have a core dev
Discord server I figured it made sense to start recording this.
___
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/JTVBXPI75OIEIM55ZJVVRK7RHUX5JZMH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Ammar Askar to the team!

[Brett Cannon]

___
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/IRALWXKYDQSOZLXDSZC2GVTA7DPWCTKD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please make sure you're following good security practices with your GitHub account

[Brett Cannon]

On Tue, Jun 15, 2021 at 11:08 AM Mariatta  wrote:

> Thanks for sharing your experience, and I think it's important for us core
> developers to be careful and vigilant about this.
>
> I was wondering if we should add under the "core developers
> responsibility" section (
> https://devguide.python.org/coredev/#responsibilities), about securing
> their GitHub account with 2FA/MFA? I think this is something that can be
> made as required by the org admins. (and add that we'll work with folks if
> they need assistance in setting those up).
>

Yes, there's a setting at I believe the org level where we can require 2FA.
I've tossed something on the SC agenda (which is currently massive, so who
knows how long it will be before we get to this) to see if this is
something we want to consider (if 2FA would actually stop you from
contributing, do feel free to speak up, otherwise I assume it's a situation
like Tim where we just need to help you figure out how to make it work).

-Brett


>
>
>
> On Mon, Jun 14, 2021 at 12:38 PM Brett Cannon  wrote:
>
>> I have discovered someone tried to break into my GitHub account (you can
>> check yourself by going to https://github.com/settings/security-log and
>> looking for "failed to login" attempts for potentially odd geographical
>> locations for yourself). CPython probably would have been the biggest
>> target for them had they gotten in (my work stuff is all open source and it
>> would have required breaking into another account). But GitHub has a
>> completely unique password and MFA turned on, so they were unsuccessful.
>>
>> Please make sure you have a unique password for your GitHub account and
>> that you have 2FA/MFA turned on (I honestly think we should start requiring
>> this; I'm sure we can get money for folks to get security keys). Other
>> languages like PHP have been successfully hacked (
>> https://arstechnica.com/gadgets/2021/03/hackers-backdoor-php-source-code-after-breaching-internal-git-server/),
>> so this isn't a hypothetical anymore that we would be targets for folks who
>> want to install a backdoor into one of the world's most popular programming
>> languages and is now mission-critical for a lot of massive corporations and
>> governments.
>> ___
>> 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/IS5ZGCRBBZ2RRRBJO4ZPG6P6XDPSDEYI/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
___
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/U34DM5HVDFKF7KNC2KKGMFUEFKEDNCJ2/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Please make sure you're following good security practices with your GitHub account

[Brett Cannon]

I have discovered someone tried to break into my GitHub account (you can
check yourself by going to https://github.com/settings/security-log and
looking for "failed to login" attempts for potentially odd geographical
locations for yourself). CPython probably would have been the biggest
target for them had they gotten in (my work stuff is all open source and it
would have required breaking into another account). But GitHub has a
completely unique password and MFA turned on, so they were unsuccessful.

Please make sure you have a unique password for your GitHub account and
that you have 2FA/MFA turned on (I honestly think we should start requiring
this; I'm sure we can get money for folks to get security keys). Other
languages like PHP have been successfully hacked (
https://arstechnica.com/gadgets/2021/03/hackers-backdoor-php-source-code-after-breaching-internal-git-server/),
so this isn't a hypothetical anymore that we would be targets for folks who
want to install a backdoor into one of the world's most popular programming
languages and is now mission-critical for a lot of massive corporations and
governments.
___
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/IS5ZGCRBBZ2RRRBJO4ZPG6P6XDPSDEYI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: core-dev chat

[Brett Cannon]

As a data point for where newer language communities have ended up, Rust is
on Discord and Zulip.

On Fri., May 14, 2021, 19:14 Dong-hee Na,  wrote:

> Believe it or not, there are people who are not familiar with the IRC
> culture.
> And those people are who enter the opensource culture after the 2010s.
> That period coincides with the growth of GitHub.
>
> So I'm also a supporter of new communication tools.
> Here the list below is my consideration.
>
> a) Are people familiar?
> If the tools are widely used by the tech company, I'd like to give the
> score.
> Because if the people are not familiar, it loses accessibility and maybe
> nobody use after some period.
>
> b) Does it has a thread feature?
> I believe that most of the core devs need this feature since I observe
> that we discuss some topics intensively for long periods of time.
>
> c) Does it has a secret channel?
>
> d) Can we get a sponsor from the provider or PSF for using the tools.
> Because most of the tools have a subscription system and without that, we
> can not use the advanced features.
> For example, with free tier Slack, we lose old historical data.
>
> So here is final my preferred list of that consideration
> >>>  ["Slack", "Discord", "Teams"]
>
> But my personal recent experience with the Discord public server was not
> that good.
> Because I got a lot of personal talks invitation that is actually spam
> or scam.
> So I exit the channel after the sprint is ended even though I use Discord
> personally.
> If we choose Discord, I'd like to suggest creating a new server for PSF,
> not the rendezvous with the existed server.
> This is the same opinion with Slack if we have the possibility to meet
> with the same issue.
>
> Regards,
> Dong-hee
>
>
> 2021년 5월 14일 (금) 오전 8:39, Senthil Kumaran 님이 작성:
>
>> Hello Core Dev,
>>
>> I find a need for a core-dev chat service, wherein I could engage in
>> some quick effervescent conversations.
>>
>> It is like a team chat, that is popular with remote work these days.
>> We even seem to have used Zoom Chat yesterday!
>>
>> * I know #python-dev in IRC exists, but it is mostly a channel for
>> bots to send notifications, and there are plenty.  I am not certain if
>> any core dev is active there. There was a time when this was active.
>> * We tried python discord last year, and were bit overwhelmed with the
>> number of channels and inability to customize
>> * There seems to be Slack called pyslackers too[1]. I am yet to try it.
>>
>> To have a proper team-chat, we need a service (a) as well as (b) team
>> using that.
>>
>> Does anyone else feel the need? Should we explore any? My thoughts and
>> options are
>>
>> a) Resurrect #python-dev - changing notifications to different group.
>> b) Request for core-dev in pyslackers Slack
>> c) Request for core-dev in Discord.
>>
>> Any other ideas are welcome.
>>
>> If you think that chatting is not a good idea, and a mailing list, and
>> discourse(discuss.python.org) are the best option, please share your
>> thoughts as well.
>>
>> If we feel a chat service will be a good idea for core-dev to
>> hangaround, then we can go to stage 2 of choosing the service by votes
>> in discourse (discuss.python.org).
>>
>>
>> Thank you,
>> Senthil
>> ___
>> 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/BVPITIYRECSGCX2JUTMT7F7CCCYQSK4K/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> 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/KMPHL7FMPLADQ4CYLXO5DYAEYCXUIM6A/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/4XTHYNRO2QJJKT5O4LNYBHZMUG2J/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: core-dev chat

[Brett Cannon]

On Fri, May 14, 2021 at 6:48 AM Senthil Kumaran  wrote:

> On Fri, May 14, 2021 at 09:36:52AM +0200, Antoine Pitrou wrote:
> > #python-dev on IRC has been wildly successful until perhaps 2015.
> > Personally, I would have no problem using IRC if wanted to connect to a
> chat
> > for CPython at all.
>
> I know, it was useful, and #python is still. The bot, github, buildbot
> made it more alerts only. Looks like Victor and few others still use it.
>
>
> > Similarly, I would have no problem using Zulip.  I would even say that
> Zulip
> > is by far the best chat system I've ever used, and the alternatives don't
> > come near.  Its threading system is really superior to everything else.
>
> With Zulip, I find it hard to understand, why I need two namespaces (for
> lack of better term) before I start writing my text in Zulip chat.
>
> #topic->subtopic [content]
>
> I have not been a part of the community that uses Zulip effectively, so
> I haven't learnt it well.
>
> > The idea that if people don't use IRC and Zulip, then we should try
> another
> > chat system, sounds like magical thought. What kind of properties do
> Slack,
> > Gitter or Discord have that Zulip doesn't? They are actually quite
> annoying
> > in my experience.
>
> Some have community advantage. K8s, Golang people are on Slack. Multiple
> Companies are on Slack, technical barrier is very low. Similar is the
> case with Discord.
>

Yeah, I don't know if the Python community as a whole has totally settled
on a platform.


>
> Community usage, and usability _perhaps_ go hand in hand. General numbers
> could support for this.
>
> That said. If we (a quorum) feel comfortable using anything like IRC,
> Zulip, I agree, we don't need another one.
>

You could launch a poll on discuss.python.org and see if there's a clear
winner.

-Brett


>
> --
> Senthil
> ___
> 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/LYK567UL32MQS7IBRFADWM5WIN3AY57Q/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/CG4MJEDHXTKT76DY5UARV4SSFZYX7VQ7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Irit Katriel to the team!

[Brett Cannon]

EOM
___
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/RJLSGQW233DBYJWKXGHCXVZUKLMOTYJR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Vote to promote Irit Katriel

[Brett Cannon]

On Thu, Apr 29, 2021 at 3:54 PM Senthil Kumaran  wrote:

> Thanks for posting this here.
>
> I might have missed this vote if it were not posted here. I rarely visit
> discourse. Should we consider forwarding the first post of "committers"
> category to this mailing list?
>

If someone knows of a way to make that work in Discourse I would personally
support it.

-Brett


>
> --
> Senthil
>
> On Thu, Apr 29, 2021 at 01:55:25PM -0700, Brett Cannon wrote:
> > https://discuss.python.org/t/vote-to-promote-irit-katriel/8457
>
> > ___
> > 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/OR53G2E5SCMSJEGQ42ZWSZYHMGOM66YL/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
___
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/NQOFXAVBLDUEYEGY2WWCGBOUSVDCWW6I/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Irit Katriel

[Brett Cannon]

https://discuss.python.org/t/vote-to-promote-irit-katriel/8457
___
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/OR53G2E5SCMSJEGQ42ZWSZYHMGOM66YL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Using CODEOWNERS in the peps repo for core dev authors and sponsors

[Brett Cannon]

We have added https://github.com/python/peps/blob/master/.github/CODEOWNERS
to the peps repo to help automatically add core devs who are authors or a
sponsor of PEPs to PRs. This will help alleviate the load on the PEP
editors as a decent chunk of time is taken up routing PRs to the
appropriate core dev. Any core dev who is inactive is not listed in the
file.

For all future PEPs, please make sure to update the CODEOWNERS file if you
are an author or sponsor for a PEP.
___
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/UD3CI56YQIXG3ZW4ASPS7MZFNQF3EXOC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Call for resumes: Developer-in-Residence to support CPython

[Brett Cannon]

On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska  wrote:

>
>
>
> On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner  wrote:
>
>> Hi Ewa,
>>
>> This is really awesome! It's great that the PSF can now hire someone for
>> that!
>>
>> The job offer is great, but I would like some clarification :-) (While
>> I was part of the previous Steering Council who helped to write the
>> job offer, sadly I was not avaialble last months when it was
>> discussed.)
>>
>>
>> Who is going to "manage" the candidate?
>>
>
> Great question! The technical direction will come from the SC and the
> people management will be Ee and myself.
>
>>
>>
>> On Mon, Apr 5, 2021 at 7:30 PM Ewa Jodlowska  wrote:
>> > The Developer-in-Residence will work full-time for one year to assist
>> CPython maintainers and the Steering Council. Areas of responsibility will
>> include analytical research to understand the project's volunteer hours and
>> funding, investigation of project priorities and their tasks going forward,
>> and begin working on those priorities. We are looking to hire an existing
>> core developer because of the type of work involved and interaction with
>> volunteer core developers and contributors. Need and available funding will
>> determine any extension beyond the first year.
>> >
>> > Create metrics (...) Combine usage and surveyed metrics to determine
>> which standard library modules need help and what the maintainer cost is
>> for standard library modules
>>
>> What are the expected steps after the production of such report of the
>> stdlib usage and maintenance? Hire more people to maintain most used
>> stdlib modules, or deprecate least used modules?
>>
>
>> For example, asyncio and ctypes are popular but barely maintained. For
>> the CI, the most unstable test is test_asyncio (I asked for help
>> multiple times on python-dev). Do we need a more detailed reports on
>> the 302 (len(sys.stdlib_module_names)) stdlib modules?
>>
>
> One of the intentions is to document these cases to better prioritize
> funding we have and provide direction to potential future funders.
>
> I am sure someone from the Steering Council will want to chime in on
> additional, more technical intentions :)
>

I think the results of the research is going to help inform what the next
steps are (hence the need for the research ). Guessing what needs work
and making a call without having at least *some* form of data seems
premature. I also have stdlib data already for a language summit discussion
(if it gets selected), and at worst I will just open source the Jupyter
notebook with the charts of what I found so this won't be starting from
scratch.

Plus I suspect there will be some discussion here of what people want to
see be worked on. While the SC is the final decider on the priorities
simply because it would probably be a bit chaotic if the whole team tried
to direct a single person's work, that doesn't mean things won't be
discussed here to provide guidance and feedback to the SC.


>
>
>>
>> I understand that the first step is to put priorities in bug triage
>> and PR reviews for the candidate.
>>
>>
>> > Address Pull Request and Issue backlogs based on the developed metrics
>> and other metrics created by the Steering Council
>>
>> What about the candidate skills? I don't expect the candidate to be
>> able to fix any bug in any part of the Python. What if is the priority
>> is a module that the candidate doesn't know? They should do their
>> best, help debugging issues and propose a fix? I expect the existing
>> module maintainers to remain the local autority to review pull
>> requests written by the candidate, to avoid mistakes.
>>
>
What would *you* do in this situation? The expectation is the person would
act like any of us would: if they can fix something then fix it, otherwise
find the person who can and help them out. There is a reason we hope a core
dev is up for taking this job. 


>
>> In my experience, it usually helps a lot to do a first basic review,
>> but then ask for the maintainers of a module to do the final review
>> and merge the change. Finding the right people for a review on a
>> specific PR is a very valuable addition to a PR. The candidate could
>> be a great help for that!
>>
>
> Yes, great point to clarify. By "address" we mean either take care of it
> themselves if it is in their purview or work with the maintainers and
> support maintainers with setting up priorities/getting additional resources.
>

Exactly what Ewa said. The person is meant to be an asset to the team to
help us keep this project running as smoothly as possible. As of right now
our massive PR backlog is the obvious sticking point we have and so that's
what the SC wants to see tackled first.
___
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 

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Brett Cannon]

On Wed, Mar 3, 2021 at 1:32 PM Christian Heimes 
wrote:

> On 03/03/2021 21.54, Brett Cannon wrote:
> > Has this been submitted to the SC yet? I can't find an email or anything
> > at
> >
> https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644
> > <
> https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644
> >.
>
> Err ... no. I was not aware that I have to formerly submit a PEP to the
> SC for approval. I thought that pushing the PR and announcing it on DPO
> was good enough.
>

We ask people to explicitly tell us when they are ready for a PEP to be
reviewed as we otherwise don't know when you as a PEP author think the PEP
is in a finished state and is no longer changing. Otherwise we would be
reading PEPs that are constantly changing underneath us as the conversation
happens and PEP authors update things accordingly.

The preference is opening an issue at
https://github.com/python/steering-council/issues as it's the easiest way
for us to track what we are being asked to consider and for other PEP
authors to know what our review queue looks like (currently sits at 5 PEPs).
___
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/AM235PHNN5FSI4QXWTLNVETFDJU4N5OK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Brett Cannon]

On Wed, Mar 3, 2021 at 8:08 AM Christian Heimes 
wrote:

> On 03/03/2021 16.06, Senthil Kumaran wrote:
> > On Tue, Mar 2, 2021 at 8:29 PM Gregory P. Smith  wrote:
> >>
> >> For lack of better things to do with that...
> https://bugs.python.org/issue43382 filed to track it.
> >
> > Actually, that turned out to be useful. Thank you!
> >
> > The discussion with the default minimal level TLS, and way it is
> > configured in distributions like Ubuntu, Debian, Fedora, and it's
> > usage with Python is  bit _unsettling_ from a users perspective.
> > OpenSSL, Ubuntu, Python are heavily relied upon pieces of
> > infrastructure. I wouldn't be surprised if more projects noticed this
> > problem with the update to Ubuntu 20.02.
>
> Hi,
>
> for the record, the issue started when GitHub Actions updated
> "ubuntu-latest" was updated from 18.04 to 20.04. A user reported a
> similar issue on BPO last year in August and with Ubuntu last year in
> October. Only Ubuntu is affected. Debian, standard OpenSSL, and other
> distros use a different approach set minimum protocol version:
>
> https://bugs.python.org/issue41561
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625
>
>
> PEP 644 (not approved yet)


Has this been submitted to the SC yet? I can't find an email or anything at
https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644
.

-Brett


> and a soon-to-be-published PEP will hopefully
> get rid of the problem once and for all. PEP 644 removes support for
> OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1
> from stdlib.
>
> https://www.python.org/dev/peps/pep-0644/
>
>
> By the way, all major distributions disable TLS 1.0 and 1.1. They also
> set a higher security level to block weak RSA, DH, and signatures. You
> can find more information about Fedora crypto policies at:
>
> https://fedoraproject.org/wiki/Changes/CryptoPolicy
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
>
>
> Here are some of my fixes for crypto policies, TLS 1.0/1.1 deprecation,
> and FIPS:
>
> https://bugs.python.org/issue34399
> https://bugs.python.org/issue38275
> https://bugs.python.org/issue38271
> https://bugs.python.org/issue34542
>
> Christian
> ___
> 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/JO3PCRIIG36GW2ZBRCSWUHNBXPUURYUW/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/HMOPREK7N3J44MLTUWFUJZRJQJ62QPMU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: bedevere/issue-number and bedevere/news: waiting for status to be reported

[Brett Cannon]

BTW if people want to help move Bedevere's functionality out of the bot and
into GitHub Actions so it's more visible and easier for others to help
maintain then that would be appreciated  (I'm planning to spend my
holidays developing a GitHub Action to take over the news entry file check
and very likely our file regeneration, for instance).

On Sat, Dec 19, 2020 at 2:52 PM Eric V. Smith  wrote:

> Thanks, Mariatta.
>
> I just removed the "skip issue" tag, and presto: "All checks have passed".
> I'm not sure what's up, but at least I can merge this issue now.
>
> Eric
> On 12/19/2020 3:24 PM, Mariatta wrote:
>
> I tried removing the labels and adding them back. I didn't see any error
> logged in heroku. The app is running, yet the webhooks appeared to be
> delivered successfully, returning 200 status.
>
> Perhaps there's a problem from GitHub side.
>
> I'm on my phone right now and not able to further investigate until later
> this evening.
>
>
> On Sat., Dec. 19, 2020, 11:50 a.m. Eric V. Smith, 
> wrote:
>
>> I'm trying to merge this: https://github.com/python/cpython/pull/23855
>>
>> It says that it's waiting on bedevere/issue-number and bedevere/news,
>> with status "Waiting for status to be reported". The PR is tagged with
>> "skip issue" and "skip news" (even though it has an issue). So I guess
>> these are inspected by bedevere, which isn't responding.
>>
>> I've tried opening and closing the issue to re-trigger things, to no
>> avail.
>>
>> What can I do to commit this PR? Does bedevere need to be kicked into
>> life somehow? Is anyone else seeing this problem?
>>
>> Thanks.
>>
>> Eric
>> ___
>> 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/4QD47S5OB4EVC6A2QTT7EH26EQBW4PGR/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> 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/L5FSQC4EEQ5LTLAWAZZ62GNT5US62HP3/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/NBSIJN54KA3RSVPYAS3YKSARJC4DAOPQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Steering Council Election Timeline for 2021 term

[Brett Cannon]

Ernest closed the nominations and we ended up with 10 nominees! Thanks to
everyone who stepped forward to serve on the SC.

I would like to encourage people to take the time to read everyone's
nomination posts as stances on a wide variety of topics ranging from
pattern matching to the Code of Conduct are covered by them. And with
Victor not running again, there's going to be, at minimum, one new person
on the SC in 2021.

https://discuss.python.org/c/core-dev/steering-council-nominations/21

On Sun, Nov 15, 2020 at 9:18 AM Victor Stinner  wrote:

> Reminder: the deadline for nomination is tonight, hurry up ;-)
>
> Current candidates can be found at:
> https://discuss.python.org/c/core-dev/steering-council-nominations/21
>
> Victor
>
> Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska  a écrit :
> >
> > Hi!
> >
> > The timeline for this year's election will be the same as last year.
> >
> > * The nomination period will begin Nov 1, 2020 (do not post nominations
> until then)
> > * Nomination period will end Nov 15, 2020
> > * Voting will begin Dec 1, 2020
> > * Voting will end Dec 15, 2020
> >
> > Nominations will be collected via https://discuss.python.org/ (more
> details to follow on Nov 1).
> >
> > New for this year: Ernest W. Durbin III will be running the vote along
> with the assistance of Joe Carey, a PSF employee. They will be co-admins
> going forward. I have cc'ed them in on this thread as well in case there
> are any questions.
> >
> > Thanks,
> >
> > Ewa
> >
> > ___
> > 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/JHYSU6FEYM3A5AZXSICO5OE3VAWDPGEJ/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/LTAY635DKLMR2655CQN2S5Z7YBILDF24/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/CECK4QMWBDUAS4EXYQAZBVWBC6R3S6KS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Gauging sentiment around pattern matching

[Brett Cannon]

During the latest SC meeting we discussed the fact  that none of us felt we
had a clear view of whether consensus was around pattern matching and the
current PEPs exists simply due to the volume of discussion. As such we
decided to create a poll to see what the general feeling was among
everybody:

https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770

As mentioned in the poll, this is non-binding and mainly to help the SC
understand if any form of consensus exists among ourselves. This poll will
close in a week.
___
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/SB4JB6BFX4CGS3ANKKMTL47NKPA73JXK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Batuhan Taskaya to the team!

[Brett Cannon]

___
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/23C4CKSESDVFUVJCSZ4X3U7CUPUJKWUP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is adding an email package "defect" a new feature?

[Brett Cannon]

Our lesson from our "innocuous" addition of booleans makes me leery of
anything that tweaks the API such that it isn't compatible in the same
feature release.

On Fri, Oct 23, 2020 at 3:16 PM Barry Warsaw  wrote:

> Over in:
>
> * https://bugs.python.org/issue30681
> * https://github.com/python/cpython/pull/22090
>
> Georges Toth has a PR that fixes some problems with
> email.utils.parsedate_to_datetime().  I like the PR, and am ready to
> approve it for 3.10.  Georges would like it back ported, which I would be
> normally be okay with *except* that it adds a new “defect” class.
>
> Defects are a way for the email parser to indicate problems with the
> incoming data without throwing an exception.  This is an important
> constraint because we never want clients of the parser to have to deal with
> exceptions.  So if e.g. a message had some formatting or syntactic problem,
> but was otherwise parseable, you’d still get an email object back from the
> parser, but attached to it would be a list of defects that were
> encountered.  Clients then could choose to ignore or handle these defects
> depending on the use case.  Defects are implemented as classes that get
> instantiated with some useful information and appended to an email
> message’s “defects” list.
>
> PR #22090 adds an InvalidDateDefect for cases where parsing the Date:
> header encounters problems, such as an invalid hour value.  I think this is
> the right thing to do to fix the reported bug, but I am on the fence as to
> whether this new defect class should prevent back porting.  OT1H, it can’t
> break existing code, but OTOH this defect will only be found when run in
> Python bug fix releases with the new defect detection.
>
> What do you think?  And especially, what does Łukasz think, since he’s the
> RM for back port candidates 3.8 and 3.9?
>
> Cheers,
> -Barry
>
> ___
> 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/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/JYKOH4XXAMAUI7IXVNC2WMHQVBP5FSKC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 641: Using an underscore in the version portion of Python 3.10 compatibility tags

[Brett Cannon]

https://www.python.org/dev/peps/pep-0641/ (once the cron job runs)

https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513
for discussions.

This was discussed at the core dev sprints and has RM sign-off. The plan is
to discuss this at the next steering council meeting where I will advise to
make Pablo the PEP delegate.

The main reason for the PEP is for visibility, give people something to
point to, and to see if this plan raises any major red flags somehow.
___
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/PK4V5YMMMAJHU4LENUOCNCMFSH3PUKUS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Making it easier to track who is currently considered "active" for voting

[Brett Cannon]

On Tue, Oct 20, 2020 at 3:07 PM Brett Cannon  wrote:

>
>
> On Tue, Oct 20, 2020 at 2:58 PM Nathaniel Smith  wrote:
>
>> How are you measuring "activity"? Just commits?
>>
>
> Same as it has always been since the voters repo has existed and we
> automated any of this: you either committed or authored a change in the
> CPython repo. So you can either author a PR that someone else merges or you
> can merge someone else's PR and that counts as active (or author and merge
> your own PR).
>
>
Or to be specific:
https://github.com/python/voters/blob/master/coredev/active.py.


> -Brett
>
>
>>
>> On Tue, Oct 20, 2020 at 12:16 PM Brett Cannon  wrote:
>>
>>> With the next SC election fast approaching, I did the final tweaks I
>>> wanted to make to the voters repo to address visibility issues we had in
>>> the last election.
>>>
>>> First, there is now a monthly cron job that will run at
>>> https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter+Roll%22
>>> which will project a Dec 01 vote and then calculate who would fall off the
>>> voter roll based solely on activity, who would be added, and then the full
>>> list of voters. What that means is the two year of activity is calculated
>>> back from the next Dec 01, so you can check to see if you haven't committed
>>> or authored code in that timeframe to automatically be put on the voter
>>> roll.
>>>
>>> Second, I created
>>> https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+Roll%22
>>> for manually creating the voter roll. This means people can manually
>>> trigger the same code used to create the initial voter roll and see who
>>> would (not) be automatically placed on it. I expect this to mostly be used
>>> by the folks running the election. And I do advise specifying the full date
>>> as the input instead of using the MM-DD shortcut if you choose today as it
>>> will most likely wrap around to projecting a vote next year.
>>>
>>> Finally, I updated the data to include when someone left the core team
>>> (and if someone was ejected, which is a term from PEP 13). For those that
>>> never entered a GitHub username, I implicitly put them as having left the
>>> team the day the first PR was merged on GitHub since they stopped being
>>> able to participate actively from that day forward with an appropriate note
>>> as to why (2017-02-10). This is now shown in the developer log at
>>> https://devguide.python.org/developers/.
>>>
>>> Hopefully this is enough to easily check if one should try to get a
>>> quick PR committed and/or authored before an election. We can all also try
>>> to remember to include it in the vote announcement email going forward if
>>> anyone forgets.
>>> ___
>>> 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/DLJE25TWAQ2KBGVJUSUO4W7KSZYHFFVC/
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
>>
>
___
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/QH7C32P52VDH5MR4ZMRWKYJRJLC5W2OO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Making it easier to track who is currently considered "active" for voting

[Brett Cannon]

On Tue, Oct 20, 2020 at 2:58 PM Nathaniel Smith  wrote:

> How are you measuring "activity"? Just commits?
>

Same as it has always been since the voters repo has existed and we
automated any of this: you either committed or authored a change in the
CPython repo. So you can either author a PR that someone else merges or you
can merge someone else's PR and that counts as active (or author and merge
your own PR).

-Brett


>
> On Tue, Oct 20, 2020 at 12:16 PM Brett Cannon  wrote:
>
>> With the next SC election fast approaching, I did the final tweaks I
>> wanted to make to the voters repo to address visibility issues we had in
>> the last election.
>>
>> First, there is now a monthly cron job that will run at
>> https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter+Roll%22
>> which will project a Dec 01 vote and then calculate who would fall off the
>> voter roll based solely on activity, who would be added, and then the full
>> list of voters. What that means is the two year of activity is calculated
>> back from the next Dec 01, so you can check to see if you haven't committed
>> or authored code in that timeframe to automatically be put on the voter
>> roll.
>>
>> Second, I created
>> https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+Roll%22
>> for manually creating the voter roll. This means people can manually
>> trigger the same code used to create the initial voter roll and see who
>> would (not) be automatically placed on it. I expect this to mostly be used
>> by the folks running the election. And I do advise specifying the full date
>> as the input instead of using the MM-DD shortcut if you choose today as it
>> will most likely wrap around to projecting a vote next year.
>>
>> Finally, I updated the data to include when someone left the core team
>> (and if someone was ejected, which is a term from PEP 13). For those that
>> never entered a GitHub username, I implicitly put them as having left the
>> team the day the first PR was merged on GitHub since they stopped being
>> able to participate actively from that day forward with an appropriate note
>> as to why (2017-02-10). This is now shown in the developer log at
>> https://devguide.python.org/developers/.
>>
>> Hopefully this is enough to easily check if one should try to get a quick
>> PR committed and/or authored before an election. We can all also try to
>> remember to include it in the vote announcement email going forward if
>> anyone forgets.
>> ___
>> 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/DLJE25TWAQ2KBGVJUSUO4W7KSZYHFFVC/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
>
___
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/56A76JAYEO7ND6NQTS4AFLSIGEN35RK2/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Making it easier to track who is currently considered "active" for voting

[Brett Cannon]

With the next SC election fast approaching, I did the final tweaks I wanted
to make to the voters repo to address visibility issues we had in the last
election.

First, there is now a monthly cron job that will run at
https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter+Roll%22
which will project a Dec 01 vote and then calculate who would fall off the
voter roll based solely on activity, who would be added, and then the full
list of voters. What that means is the two year of activity is calculated
back from the next Dec 01, so you can check to see if you haven't committed
or authored code in that timeframe to automatically be put on the voter
roll.

Second, I created
https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+Roll%22
for manually creating the voter roll. This means people can manually
trigger the same code used to create the initial voter roll and see who
would (not) be automatically placed on it. I expect this to mostly be used
by the folks running the election. And I do advise specifying the full date
as the input instead of using the MM-DD shortcut if you choose today as it
will most likely wrap around to projecting a vote next year.

Finally, I updated the data to include when someone left the core team (and
if someone was ejected, which is a term from PEP 13). For those that never
entered a GitHub username, I implicitly put them as having left the team
the day the first PR was merged on GitHub since they stopped being able to
participate actively from that day forward with an appropriate note as to
why (2017-02-10). This is now shown in the developer log at
https://devguide.python.org/developers/.

Hopefully this is enough to easily check if one should try to get a quick
PR committed and/or authored before an election. We can all also try to
remember to include it in the vote announcement email going forward if
anyone forgets.
___
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/DLJE25TWAQ2KBGVJUSUO4W7KSZYHFFVC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

[Brett Cannon]

On Mon, Oct 19, 2020 at 11:22 AM Ned Deily  wrote:

> On Oct 19, 2020, at 13:59, Brett Cannon  wrote:
> > On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman  wrote:
> >> On 10/18/20 1:18 PM, Ned Deily wrote:
> >> > On Oct 18, 2020, at 15:45, Carol Willing  wrote:
> >> >> We've largely moved away from Travis for Jupyter testing in favor of
> Azure pipelines and CircleCI as Travis was becoming increasingly slow and
> timing out.
> >> >
> >> > Along those lines, if we are basically going to ignore the Travis CI
> results, perhaps we should consider being "good citizens" and stop running
> them all together.  Each PR change triggers multiple builds to run under
> Travis and all that extra and useless work contributes to the load on
> Travis and no doubt is not good for overall Travis responsiveness.
> >>
> >> If we have something else set up to takes its place that's fine;
> otherwise, let's leave it up with the understanding
> >> that we have to check it manually for success or failure -- that's
> still valuable information.
> > Unfortunately, the "valuable information" lately has been whether Travis
> is even working. 
>
> Yes, and I still think it's unfair of us to use so much of Travis's
> resources - resources that other projects could use - when we are almost
> entirely ignoring the results.  On the master branch, each time a PR is
> merged or requires a CI run, we currently start up to 5 separate Travis
> jobs (some short-circuited but still jobs). The main job. which rebuilds
> python and runs the test suite, can run for 15+ minutes.  And then
> backports run some of the jobs as well.
>

Yep, if Travis has limited their free resources then we are wasting them.
And without knowing where Travis gets their electricity there's even a
potentially (very slight) ecological cost from us wasting the runs. I am
with Ned about trying on to be wasteful here *just* *in case* Travs happens
to find something in a CI run.


>
> Let's just disable Travis on all branches for now until there is reason to
> believe the problems we've seen are fixed.
>

+1 from me.


>
> --
>   Ned Deily
>   n...@python.org -- []
> ___
> 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/AYLXEBIFHWCODJSIRS3W2C2HSQKHYRHM/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/IRHJ23U4AWODZFNWK3PCB2PDIRXAEQSB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

[Brett Cannon]

On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman  wrote:

> On 10/18/20 1:18 PM, Ned Deily wrote:
> > On Oct 18, 2020, at 15:45, Carol Willing  wrote:
> >> We've largely moved away from Travis for Jupyter testing in favor of
> Azure pipelines and CircleCI as Travis was becoming increasingly slow and
> timing out.
> >
> > Along those lines, if we are basically going to ignore the Travis CI
> results, perhaps we should consider being "good citizens" and stop running
> them all together.  Each PR change triggers multiple builds to run under
> Travis and all that extra and useless work contributes to the load on
> Travis and no doubt is not good for overall Travis responsiveness.
>
> If we have something else set up to takes its place that's fine;
> otherwise, let's leave it up with the understanding
> that we have to check it manually for success or failure -- that's still
> valuable information.
>

Unfortunately, the "valuable information" lately has been whether Travis is
even working. 

-Brett


> ___
> 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/XAJE43CDSNJYMYJVQEZ7TSXB7FGW57YD/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/XZGDR7WYEIMKZAATYJFIQ5VX3ZKOOCMF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

[Brett Cannon]

On Fri, Oct 16, 2020 at 11:58 AM Pablo Galindo Salgado 
wrote:

> > We should simply mark the github actions "Tests / Ubuntu" CI as
> required.
>
> +1 I completely agree with everything Gregory said.
>

+1 from me as well.

-Brett


>
>
> On Fri, 16 Oct 2020 at 19:36, Gregory P. Smith  wrote:
>
>>
>>
>> On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner 
>> wrote:
>>
>>> Hi,
>>>
>>> Python has no mandatory Linux CI job on pull requests anymore. Right
>>> now Windows (x64) remains the only mandatory job. Please be careful to
>>> manually check other CI before merging a PR.
>>>
>>> --
>>>
>>> We had to deal with at least 3 different issues on the Travis CI over
>>> the last 6 months. The latest one (3rd issue) is on the Travis CI side
>>> and is known for months. Sometimes, a Travis CI build completes but
>>> the GitHub pull request is never updated. Since Travis CI was
>>> mandatory, it was never possible to merge some pull requests. I also
>>> noticed a 4th bug, sometimes a PR gets *two* Travis CI jobs on a PR
>>> for the same Travis CI build, only one is updated, and so again, the
>>> PR cannot be merged.
>>>
>>> For all these reasons, Travis CI was made optional.
>>>
>>> I would be nice to have a mandatory Linux job: "Tests / Ubuntu
>>> (pull_request)" is a good candidate. But I didn't check if it's
>>> reliable or not.
>>>
>>
>> We should simply mark the github actions "Tests / Ubuntu" CI as required.
>>
>> If we wind up not liking the behavior we can go back on it while we work
>> something else out.  But it seems dangerous to not have any blocking Linux
>> CI.  Linux is our most important platform.  With our dev sprint next week
>> we'll discover if it gets in our way more often than helps rather quickly.
>>
>> I cannot rightfully apply an automerge label to a code PR so long as we
>> lack Linux CI to block a merge.
>>
>> -gps
>>
>>
>>>
>>> See https://github.com/python/core-workflow/issues/377 for the
>>> discussion.
>>>
>>> Note: if someone manages to fix all Travis CI issues, we can
>>> reconsider making it mandatory again. But it seems like most people
>>> who tried (included me) are tired or bored by Travis CI.
>>>
>>> Victor
>>> --
>>> Night gathers, and now my watch begins. It shall not end until my death.
>>> ___
>>> 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/JR7HIQHVECHPKH2LE46EACN73KCBLVKE/
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>> ___
>> 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/7YTWVS5OXH3NJQBSG55QBSXOMD6RECFG/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> 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/PRZ6USPKAEVZHBO5MUWYDK37O3PYBSG4/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/FWLOA2SCCKB4RUMDOCTNVIMHNKMEPTYD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

[Brett Cannon]

Should we consider dropping Travis CI as a CI provider if it continues to
be so flaky? Otherwise isn't it becoming just noise on a PR?

On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner  wrote:

> Hi,
>
> Python has no mandatory Linux CI job on pull requests anymore. Right
> now Windows (x64) remains the only mandatory job. Please be careful to
> manually check other CI before merging a PR.
>
> --
>
> We had to deal with at least 3 different issues on the Travis CI over
> the last 6 months. The latest one (3rd issue) is on the Travis CI side
> and is known for months. Sometimes, a Travis CI build completes but
> the GitHub pull request is never updated. Since Travis CI was
> mandatory, it was never possible to merge some pull requests. I also
> noticed a 4th bug, sometimes a PR gets *two* Travis CI jobs on a PR
> for the same Travis CI build, only one is updated, and so again, the
> PR cannot be merged.
>
> For all these reasons, Travis CI was made optional.
>
> I would be nice to have a mandatory Linux job: "Tests / Ubuntu
> (pull_request)" is a good candidate. But I didn't check if it's
> reliable or not.
>
> See https://github.com/python/core-workflow/issues/377 for the discussion.
>
> Note: if someone manages to fix all Travis CI issues, we can
> reconsider making it mandatory again. But it seems like most people
> who tried (included me) are tired or bored by Travis CI.
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/JR7HIQHVECHPKH2LE46EACN73KCBLVKE/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/VMOSHFBG3XWZCX2EK5R6MFKXEBSMSGGA/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Resignation from Stefan Krah

[Brett Cannon]

On Thu, Oct 8, 2020 at 5:21 PM Barry Warsaw  wrote:

> On Oct 8, 2020, at 14:34, Ethan Furman  wrote:
> >
> > Sure, but I don't know who they are.  Besides, if the SC did not do the
> banning/moderating then they should find out what happened.
> >
> > If the SC did do the banning/moderating then I'd really like to know
> why, both so that I can make sure and not do that thing myself, and so that
> I can caution others who are straying down that path.  That's handy
> information to have, especially when you're a mailing list moderator.
>
> Thank you, Ethan.
>
> The Steering Council did indeed ban Stefan, as Thomas’ followup email just
> now sent elaborates on.  This was the first time that the SC has had to
> take such actions, and we neglected to notify the mailing list owners of
> the affected lists.


To be absolutely clear, I am an admin for -committers and -ideas, Barry is
for -dev. So an admin on all affected lists was aware of what was going on,
just not all of them for privacy reasons while we attempted to work things
out.

-Brett





>   We apologize for that.  We all hope that we never have to do this again,
> but we will be sure to keep list owners in the loop should it ever be
> necessary in the future.
>
> Cheers,
> -Barry, on behalf of the Python Steering Council
>
> ___
> 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/YTC3LLSTIRSJ6DW4WRWVWALPIZHHPQS4/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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/P2PJUWPQGWT6FJFJA3BDLQUB4IDOZYAP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Brandt Bucher to the team!

[Brett Cannon]

___
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/VWLTZR5FDXFRCCRUATKBF2G4JTQCKVH7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Official joint communication from the Python Steering Council, PSF Board of Directors, and PSF Conduct WG

[Brett Cannon]

 [This has been sent to python-committers, python-dev, and python-ideas]

Recently, a series of discussions on this mailing list resulted in behavior
that did not live up to the standards of the Python Community. The PSF
Board of Directors, Python Steering Council, and the PSF Conduct Working
Group would like to remind this community that our shared goal is to
advance the Python language while simultaneously building a diverse,
inclusive, and welcoming Python community. While the community has made
progress in recent years, this discussion made it clear to many of us that
we still have room to grow.

At the request of the PSF Board, the Steering Council, and members of the
community, the PSF Conduct WG met to discuss these recent events and
recommend action. As a result, warnings will be given to several members of
the Python Community, and the Steering Council will be taking further
action.

Especially during passionate discussions like these, we'd like to ask that
all Pythonistas focus on being welcoming and respectful, and that we all
try to act in the best spirit of the Python Community.

Thank you,
Python Steering Council
PSF Board of Directors
PSF Conduct WG
___
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/M56XWU2A6JYFGTMRFIGYHFFSPDWNSKYA/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 387 has been accepted

[Brett Cannon]

For those of you not on python-dev, the SC today chose to accept PEP 387.
https://www.python.org/dev/peps/pep-0387/
___
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/LKTGJ6TMCARWFNARNDYJIJLO32T543PT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Please welcome Lysandros Nikolaou to the team!

[Brett Cannon]

___
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/OQPA633CV5TA44BBYFBMU3CI4WRT4AVC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Experimental isolated subinterpreters

[Brett Cannon]

Can we wait until after 3.10 development opens up? And could it be a `-X` flag?
___
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/VG4FOYZELZIXHH5UHU76PJKYHK4FF47V/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Language Summit

[Brett Cannon]

joannah nanjekye wrote:
> Hey all,
> Unfortunately this year am too busy and cant even attend the language
> summit mostly.

:( Sorry to hear that.

> However if I knew the schedule, I could sign up for a session or two online.

Schedule can be found at https://us.pycon.org/2020/events/languagesummit/.

> Are we going to have recordings of the sessions this year given its a zoom?

I personally don't know, but my guess is no for privacy reasons. But Jesse will 
be attending to write up a blog post about what occurs.

-Brett

> A chance to catch up later.
> Best,
> Joannah Nanjekye
> "You think you know when you learn, are more sure when you can write, even
> more when you can teach, but certain when you can program." Alan J. Perlis
___
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/TQ67ZFA6FCQNXZMRZDY27PYYDMQJRD3Q/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Kyle Stanley to the team!

[Brett Cannon]

And just in time for the language summit! :)
___
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/6MD34LIFZ4CKAQJ2IEGQBOLTX5KFYTGM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Dong-hee Na to the team!

[Brett Cannon]

Dong-hee Na wrote:
[SNIP]
> cc.
> If I had to wait for the announcement of the Steering Committee
> (https://discuss.python.org/t/vote-to-promote-dong-hee-na/3794/2
> )
> before writing this email,
> Thank you for your understanding in advance.

Nope, no need to wait. Me granting access came after the steering council 
cleared your nomination.
___
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/BHOJWJ5LAKQ3ORBWE6ANRWNLUBMPDTO3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Dong-hee Na to the team!

[Brett Cannon]

Assuming I didn't botch anything, Dong-hee should be all set up!
___
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/5ZZVHJHAEHT3DW5Q3X5S336KM5FE4B2C/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Documentation on how to propose and promote someone to become a core developer

[Brett Cannon]

With two votes opened in 48 hours, I figured it was a good time to point out 
that https://devguide.python.org/coredev/#gaining-commit-privileges outlines 
the process of promoting someone from how to structure the vote to getting the 
person their commit privileges.
___
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/I6WXLUFYN6VN2G6XJ7TWYLS3MQ7ILDHC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: What is CodeCov on pull request? Does anyone use it?

[Brett Cannon]

FYI we have codecov configured to turn off the comment (and have since I think 
we started using codecov). See the issue for more details about a potential bug 
on codecov's side.
___
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/XQ3CGS6Z5IBW7YH7FA2QIOIP3K7BDI75/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Survey on strengthening the volunteer community with paid developers

[Brett Cannon]

The steering council is interested in hearing from *core developers* about
their thoughts around the idea of hiring people to help with the project.
The thinking is if we can pay people to help/assist with the aspects of
development that us volunteers do not enjoy doing or simply lack the time.
This is so we can help maximize our impact as a team of volunteers and
improve Python the best we can. We are also gathering info from folks about
what they (dis)like about the development process at the same time.

The survey can be found at https://forms.gle/p1F9utFiG3PJemaN7. We are
currently restricting this to *only core developers* and one response per
core dev. We would love responses sooner rather than later so we can
analyze the responses in time for PyCon US. Please aim to respond by Feb 15.
___
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/XJ373N2H5O2OXMEQEEGYIIZ3U7RNHVHJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome Karthikeyan Singaravelan to the team!

[Brett Cannon]

___
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/HM2P6DV5LL5V3L6TQGYFD6VVAK52RJEE/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Congratulations to all for reaching the EOL for Python 2!

[Brett Cannon]

I just wanted to say congratulations to everyone for reaching this point! I 
know it has been a long time coming and quite the struggle sometimes over the 
past decade, but we reached our (extended) end for Python 2 without having the 
entire community and language collapse as some had predicted would occur when 
we started our journey to making Py3K a reality.

Hopefully everyone can enjoy watching the 2.7 branch sit there as it pines for 
the fjords and rests until April when we all can watch Benjamin click the final 
button to release Python 2.7.18 at PyCon US and send Python 2 off as it ceases 
to be (at least from our perspective ).
___
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/RRGJ5O5MO3YG7A3FDFOXDSKJ72HYJBVO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Possible bug in voting system ? (was: Re: Reminder to vote for the 2020 Steering Council)

[Brett Cannon]

I want to make two quick points and then I'm bowing out of this conversation as 
this isn't going to change anything for this vote beyond the exemption we have 
already granted and no changes to PEP 13 have been proposed. I was trying to 
avoid this conversation dragging out right now, but people keep commenting so I 
want to try and provide some visibility as to how this ended up this way and 
then ask people just wait until someone proposes something to concretely change 
PEP 13 (or at least that's what I plan to do ).

To Hynek's "code = vote" comment, technically it's "authorship or committal of 
a change in the past two years to CPython from when the voter roll was 
generated = vote". IOW you could have fixed a spelling mistake, merged a PR, or 
even made a commit and then reverted it immediately and still been 
automatically included in the voter roll. Basically the term "active" is very 
subjective and I did not want to be accused of being biased or unfair in 
declaring who was (in)active, so I did the best I could to be objective and 
automate this since there are 167 people who could potentially vote (and we 
ended up with 78 with the current set-up).

As for the "please email everyone personally", I just don't have the time to 
email 30 people that Giampolo listed or the 89 total people who could vote but 
didn't commit or author something in the past two years . But do note that me 
lacking the time doesn't mean someone else can't take it upon themselves to 
reach out to folks and let them know about them (risking) falling off in this 
vote or in future votes as all of this information and code is accessible to 
all core developers; other than Ernest's roll of managing the vote no one is in 
a place of privilege, just in a place of putting the time in. I personally have 
already sank days into making this vote work starting months ago via pulling 
together the historical record and spending all of my precious coding time at 
the core dev sprints this year writing the code to generate the voter roll, and 
so sinking even more by managing a personal email to everyone is just too much 
for me to dedicate on top of everything else.
___
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/DMQ2JMKJ6GZ74POLKJ4M5RYTBJBCZVDL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Possible bug in voting system ? (was: Re: Reminder to vote for the 2020 Steering Council)

[Brett Cannon]

We discussed the situation on the steering council and we are fine with making 
an exception for folks who felt caught off-guard asking Ernest to be added to 
the voter roll even though voting has already started.

In the new year I will work with Ernest to draft up a proposal for changing PEP 
13 to make this section of it clearer in regards to the expectations for 
qualifying to vote.
___
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/HK4LNQEA3CMSZTGOZTC766NIS4CNPG7O/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Who wants to be the next tarfile maintainer?

[Brett Cannon]

Guido van Rossum wrote:
> Once a core dev, always a core dev (unless you’re fired). Git permissions
> can be reinstated no questions asked.

What Guido said. :)

This is also why I put in so much time and effort to make sure 
https://github.com/python/voters/blob/master/python-core.toml was accurate as 
that acts as the record of who has been a core developer.

-Brett

> On Wed, Dec 4, 2019 at 15:25 Victor Stinner vstin...@python.org wrote:
> > If a core dev asks to have their commit bit removed,
> > what happens if
> > they change their mind? Do we have go through the usual vote process?
> > Or should we just add it back whenever they ask?
> > Victor
> > Le mer. 4 déc. 2019 à 21:23, Brett Cannon br...@python.org a écrit :
> > >
> > You ask me to do it. :) I have gone ahead and
> > revoked them.
> > Thanks for all your help over the years, Lars!
> > 
> > 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/D...
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> > --
> > Night gathers, and now my watch begins. It shall not end until my death.
> > 
> > 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/R...
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> > -- 
> > --Guido (mobile)
> >
___
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/5XJWQ5GVNY3HSAAGZ66LIVPDEVIEUZH6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Who wants to be the next tarfile maintainer?

[Brett Cannon]

You ask me to do it. :) I have gone ahead and revoked them.

Thanks for all your help over the years, Lars!
___
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/DWJS4I4G6DQINY4YPGG7AKJIBKHWWJJJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Steering Council Nomination Period - Begins Nov 1

[Brett Cannon]

Nominations closed out and it looks like the following people will be running:

01. Gregory P. Smith
02. Pablo Galindo Salgado
03. Kushal Das
04. Christian Heimes
05. Victor Stinner
06. Guido van Rossum
07. Thomas Wouters
08. Carol Willing
09. Barry Warsaw
10. Brett Cannon

Thanks to everyone who stepped forward to run!

The next steps are to spend the time between now and Dec 1 asking any questions 
you have of the candidates. Simultaneously, the vote will get set up. Finally, 
voting will be from Dec 01 - Dec 15 as Ewa pointed out.
___
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/CHA5RSQ64Z7HDSO4AA6YRSYR6W5J3G5L/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Everything in the project is owned communally by the team

[Brett Cannon]

The steering council was asked to address the idea of code ownership in the
project, and so we wanted to publicly state that we view everything as
communally owned by everyone on the development team. That means no one has
exclusive control over any part of the code base.

Having said that, we do recognize that there are experts who should be
consulted as appropriate for various parts of the project. Their expertise
should be listened to and weighed appropriately. But if there is a
disagreement you can always appeal to the steering council to help in
resolving the issue.

The council doesn't view this as a policy shift, just reiterating a
pre-existing one. We also just wanted to emphasize that the steering
council can act as arbitrator if a disagreement arises.
___
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/DCKAPZVXEQHP7OPS3GLEVNDXMXX5QAE6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] What it's like being on the steering council

[Brett Cannon]

In case people are thinking about nominations next month and wanted to know 
what it's like and the time commitment involved, I wrote a blog post on the 
subject at 
https://snarky.ca/what-its-like-to-be-on-the-python-steering-council/.
___
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/E4BU7HBWOP4KPYWPBB2YQEPCLULOH3KU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 13 and approval voting.

[Brett Cannon]

In case people didn't notice, the poll closed and Thomas' proposal passed with 
97% of the vote.
___
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/4PITCS3UTEODR6MF5QBFQ2JXVP73TOWM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] The PSF's new Code of Conduct and how it applies to Python's development

[Brett Cannon]

[this is being emailed out to python-committer and python-dev separately,
so apologies for those who get a duplicate email]

The steering council wanted to let everyone know that the PSF released a
new Code of Conduct which was announced at
https://pyfound.blogspot.com/2019/09/the-python-software-foundation-has_24.html
and that it applies to Python's development.

Specifically, this new Code of Conduct lists Python's development spaces
and those participating in those spaces as being under the CoC (we were
implicitly under the old CoC on PSF-sponsored and run infrastructure, but
now it's explicitly called out). So that means python-committers,
python-dev, python-ideas, everything on GitHub, discuss.python.org, core
dev sprints, PSF-sponsored conferences, etc. all fall under this CoC. The
steering council wanted to make sure people were aware of this new Code of
Conduct so no one was caught off-guard and to make sure people were aware
that it did apply to all of us. The steering council also supports this
Code of Conduct.

One other thing the steering council wanted to point out is that we believe
CoC violations should be reported directly to the Conduct WG as outlined at
https://www.python.org/psf/conduct/reporting/. The thinking is that since
we all know each other on the development team there's a good chance of a
conflict of interest if reports were to go to the steering council, and so
it's simpler to just advise people go straight to the Conduct WG (Carol and
I will recuse ourselves as appropriate since we are both on the Conduct WG).

I will also say that people have come to me personally in the past and
asked if something was a CoC violation, and going forward my answer will be
"report it to the Conduct WG and let them make that decision". Same goes
for incidents where people believe something is a CoC violation and they
want to report it to someone: let the Conduct WG know (which I have already
started telling people who come to me with CoC concerns).
___
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/6QIMLZ65D2HVBRGXRMOF2KOLFRXH4IRG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Steering Council Election Timeline

[Brett Cannon]

The steering council also proposes that no changes be made to PEP 13 between 
Nov 1 and Dec 15.
___
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/TST4UFEAOUXMPABQLXLDM6T5PHLIUQHP/
Code of Conduct: https://www.python.org/psf/codeofconduct/