Skip to content

PEP 639: Update PEP delegate, post history and CODEOWNERS #2228

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pfmoore merged 2 commits into from
Jan 20, 2022
Merged

PEP 639: Update PEP delegate, post history and CODEOWNERS #2228

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0cb8980
PEP 639: Update PEP delegate (and post history)
CAM-Gerlach Jan 12, 2022
916fede
PEP 639: Add CAM to CODEOWNERS and fix formatting typo
CAM-Gerlach Jan 20, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/CODEOWNERS
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -493,7 +493,7 @@ pep-0635.rst @brandtbucher @gvanrossum
pep-0636.rst @brandtbucher @gvanrossum
pep-0637.rst @stevendaprano
pep-0638.rst @markshannon
pep-0639.rst @pfmoore
pep-0639.rst @pfmoore @CAM-Gerlach
Copy link
Member

@AA-Turner AA-Turner Jan 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a pedantic reading of PEP 1, I don't think PEP editors are allowed to be listed in CODEOWNERS.

Update .github/CODEOWNERS [7] such that any core developer co-author(s) or sponsor are listed for your new file such that any future pull requests will be assigned to them.

A PEP editor can be a sponsor, but the case of PEP editors being authors seems to be missed as an edge case.

However, I think it makes sense for PEP editors to be listed here, so probably better to update PEP 1 to allow this? If other @python/pep-editors agree I could propose an update the affected lines.

A

Copy link
Member

@JelleZijlstra JelleZijlstra Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I'm already listed as the owner of PEPs 673 and 675 and I'm not a core dev, so in practice we're not following this rule already. Let's amend PEP 1 to make it clear. I'd suggest wording like "any author or sponsor with write access to the PEPs repository".

Copy link
Member

@AA-Turner AA-Turner Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #2252

A

Copy link
Member Author

@CAM-Gerlach CAM-Gerlach Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that certainly seems like a clear oversight to me; PEP 1 may not have envisioned PEP editors who weren't core developers, like you, me and @JelleZijlstra are today—and it affects you too on your PEP 676, since you're the author but not a sponsor either.

pep-0640.rst @Yhg1s
pep-0641.rst @zooba @warsaw @brettcannon
pep-0642.rst @ncoghlan
Expand Down
6 changes: 3 additions & 3 deletions pep-0639.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,13 +5,13 @@ Last-Modified: $Date$
Author: Philippe Ombredanne <pombredanne at nexb.com>,
C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>
Sponsor: Paul Moore <p.f.moore at gmail.com>
PEP-Delegate: Paul Moore <p.f.moore at gmail.com>
PEP-Delegate: Brett Cannon <brett at python.org>
Discussions-To: https://discuss.python.org/t/12622
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Aug-2019
Post-History:
Post-History: 15-Aug-2019, 17-Dec-2021
Resolution:


Expand Down Expand Up @@ -1396,7 +1396,7 @@ but re-using the ``license`` key for the license expression, either by
defining it as the (previously reserved) string value for the ``license``
key, retaining the ``expression`` subkey in the ``license`` table, or
allowing both. Indeed, this would seem to have been envisioned by PEP 621
itself with this PEP in mind, in particular the first approach::
itself with this PEP in mind, in particular the first approach:

A practical string value for the license key has been purposefully left
out to allow for a future PEP to specify support for SPDX expressions
Expand Down