We've got to a point where the original standing delegations to myself and Richard Jones to act as BDFL-Delegates for metadata interoperability and pypi.python.org related aren't scaling adequately, so given Paul's recent delegation for PEP 470, and Donald handling PEP 503 directly, it seems like an opportune time to put something in writing about that.
For PyPA/distutils-sig specific PEPs, we've effectively adopted the following approach to assigning BDFL-Delegates in resolving PEPs 470 and 503:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
And translating the nominated roles to the folks currently filling them: "lead PyPI maintainer" = Donald Stufft; "lead CPython representative on distutils-sig" = me.
"PyPA core reviewer" isn't a term we've previously used, but I'm aiming to capture "has approval rights for pull requests to one or more of the PyPA maintained source code or documentation repos".
Some further details for the benefit of folks not aware of the relevant history:
* a couple of years ago, we amended PEP 1 to give the "Discussions-To" header some additional force for PEPs which don't directly affect CPython: """PEP review and resolution may also occur on a list other than python-dev (for example, distutils-sig for packaging related PEPs that don't immediately affect the standard library). In this case, the "Discussions-To" heading in the PEP will identify the appropriate alternative list where discussion, review and pronouncement on the PEP will occur."""
* we *didn't* update the section about assignment of BDFL-Delegates. Instead, I received a general delegation for packaging metadata interoperability PEPs, and Richard Jones received one for pypi.python.org related PEPs
* Richard subsequently passed the latter delegation on to Donald, since Donald had taken over as the lead maintainer for PyPI
The section in PEP 1 for CPython BDFL-Delegates reads as follows: ================================= However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. =================================
This process can be appropriately described as "volunteering to be blamed" - if a PEP from a less experienced contributor subsequently proves to be a mistake, that's on the BDFL-Delegate for saying "Yes", not on the PEP author for proposing it. Mostly though, it's so there's someone to have the final say on the fiddly little details that go into getting from a general concept to an actual implementation, without getting mired down in design-by-committee on every incidental detail.
As PEP authors, we'll also often ask someone else specifically to volunteer as BDFL-Delegate, because we trust their judgement in relation to the topic at hand (e.g. I asked Martin von Löwis to be BDFL-Delegate for the original ensurepip PEP because I knew he was skeptical of the idea, so a design that passed muster with him was likely to have suitably addressed the ongoing maintainability concerns. Guido did something similar when he asked Mark Shannon to be BDFL-Delegate for PEP 484's gradual typing).
Regards, Nick.
P.S. It's becoming clear to me that I should probably write a companion PEP to PEP 1 that specifically describes distutils-sig's usage of the PEP process (and how that differs from the normal CPython processes), but hopefully this post provides sufficient clarification for now.
If it’s more useful we could also just use an RFC repository like Rust does instead of doing a mishmash between having Python using PEPs and packaging using PEPs.
On September 4, 2015 at 11:42:21 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
We've got to a point where the original standing delegations to myself and Richard Jones to act as BDFL-Delegates for metadata interoperability and pypi.python.org related aren't scaling adequately, so given Paul's recent delegation for PEP 470, and Donald handling PEP 503 directly, it seems like an opportune time to put something in writing about that.
For PyPA/distutils-sig specific PEPs, we've effectively adopted the following approach to assigning BDFL-Delegates in resolving PEPs 470 and 503:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
And translating the nominated roles to the folks currently filling them: "lead PyPI maintainer" = Donald Stufft; "lead CPython representative on distutils-sig" = me.
"PyPA core reviewer" isn't a term we've previously used, but I'm aiming to capture "has approval rights for pull requests to one or more of the PyPA maintained source code or documentation repos".
Some further details for the benefit of folks not aware of the relevant history:
- a couple of years ago, we amended PEP 1 to give the "Discussions-To"
header some additional force for PEPs which don't directly affect CPython: """PEP review and resolution may also occur on a list other than python-dev (for example, distutils-sig for packaging related PEPs that don't immediately affect the standard library). In this case, the "Discussions-To" heading in the PEP will identify the appropriate alternative list where discussion, review and pronouncement on the PEP will occur."""
- we *didn't* update the section about assignment of BDFL-Delegates.
Instead, I received a general delegation for packaging metadata interoperability PEPs, and Richard Jones received one for pypi.python.org related PEPs
- Richard subsequently passed the latter delegation on to Donald,
since Donald had taken over as the lead maintainer for PyPI
The section in PEP 1 for CPython BDFL-Delegates reads as follows:
However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. =================================
This process can be appropriately described as "volunteering to be blamed" - if a PEP from a less experienced contributor subsequently proves to be a mistake, that's on the BDFL-Delegate for saying "Yes", not on the PEP author for proposing it. Mostly though, it's so there's someone to have the final say on the fiddly little details that go into getting from a general concept to an actual implementation, without getting mired down in design-by-committee on every incidental detail.
As PEP authors, we'll also often ask someone else specifically to volunteer as BDFL-Delegate, because we trust their judgement in relation to the topic at hand (e.g. I asked Martin von Löwis to be BDFL-Delegate for the original ensurepip PEP because I knew he was skeptical of the idea, so a design that passed muster with him was likely to have suitably addressed the ongoing maintainability concerns. Guido did something similar when he asked Mark Shannon to be BDFL-Delegate for PEP 484's gradual typing).
Regards, Nick.
P.S. It's becoming clear to me that I should probably write a companion PEP to PEP 1 that specifically describes distutils-sig's usage of the PEP process (and how that differs from the normal CPython processes), but hopefully this post provides sufficient clarification for now.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
is this a response to other thread about how/where to store specs and PEPs? If not, what in this email are you responding to?
On Sat, Sep 5, 2015 at 1:32 PM, Donald Stufft donald@stufft.io wrote:
If it’s more useful we could also just use an RFC repository like Rust does instead of doing a mishmash between having Python using PEPs and packaging using PEPs.
On September 4, 2015 at 11:42:21 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
We've got to a point where the original standing delegations to myself and Richard Jones to act as BDFL-Delegates for metadata interoperability and pypi.python.org related aren't scaling adequately, so given Paul's recent delegation for PEP 470, and Donald handling PEP 503 directly, it seems like an opportune time to put something in writing about that.
For PyPA/distutils-sig specific PEPs, we've effectively adopted the following approach to assigning BDFL-Delegates in resolving PEPs 470 and 503:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
And translating the nominated roles to the folks currently filling them: "lead PyPI maintainer" = Donald Stufft; "lead CPython representative on distutils-sig" = me.
"PyPA core reviewer" isn't a term we've previously used, but I'm aiming to capture "has approval rights for pull requests to one or more of the PyPA maintained source code or documentation repos".
Some further details for the benefit of folks not aware of the relevant
history:
- a couple of years ago, we amended PEP 1 to give the "Discussions-To"
header some additional force for PEPs which don't directly affect CPython: """PEP review and resolution may also occur on a list other than python-dev (for example, distutils-sig for packaging related PEPs that don't immediately affect the standard library). In this case, the "Discussions-To" heading in the PEP will identify the appropriate alternative list where discussion, review and pronouncement on the PEP will occur."""
- we *didn't* update the section about assignment of BDFL-Delegates.
Instead, I received a general delegation for packaging metadata interoperability PEPs, and Richard Jones received one for pypi.python.org related PEPs
- Richard subsequently passed the latter delegation on to Donald,
since Donald had taken over as the lead maintainer for PyPI
The section in PEP 1 for CPython BDFL-Delegates reads as follows:
However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. =================================
This process can be appropriately described as "volunteering to be blamed" - if a PEP from a less experienced contributor subsequently proves to be a mistake, that's on the BDFL-Delegate for saying "Yes", not on the PEP author for proposing it. Mostly though, it's so there's someone to have the final say on the fiddly little details that go into getting from a general concept to an actual implementation, without getting mired down in design-by-committee on every incidental detail.
As PEP authors, we'll also often ask someone else specifically to volunteer as BDFL-Delegate, because we trust their judgement in relation to the topic at hand (e.g. I asked Martin von Löwis to be BDFL-Delegate for the original ensurepip PEP because I knew he was skeptical of the idea, so a design that passed muster with him was likely to have suitably addressed the ongoing maintainability concerns. Guido did something similar when he asked Mark Shannon to be BDFL-Delegate for PEP 484's gradual typing).
Regards, Nick.
P.S. It's becoming clear to me that I should probably write a companion PEP to PEP 1 that specifically describes distutils-sig's usage of the PEP process (and how that differs from the normal CPython processes), but hopefully this post provides sufficient clarification for now.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 6 Sep 2015 08:31, "Marcus Smith" qwcode@gmail.com wrote:
is this a response to other thread about how/where to store specs and
PEPs?
If not, what in this email are you responding to?
I believe Donald was suggesting we could just have a PyPA specific change proposal process hosted on packaging.python.org, rather than using a variant of the PEP process.
I don't want to do that though - PyPA/distutils-sig's authority *is* delegated from python-dev through the BDFL-Delegate and Discussions-To headers in the regular PEP process, and there are going to be some proposals affecting ensurepip and distutils that still fall under python-dev rather than distutils-sig.
Dealing with the PEP repo is currently more painful than it needs to be, but that's what the forge.python.org proposals aim to address.
Cheers, Nick.
On Sat, Sep 5, 2015 at 1:32 PM, Donald Stufft donald@stufft.io wrote:
If it’s more useful we could also just use an RFC repository like Rust
does instead of doing a mishmash between having Python using PEPs and packaging using PEPs.
On September 4, 2015 at 11:42:21 PM, Nick Coghlan (ncoghlan@gmail.com)
wrote:
We've got to a point where the original standing delegations to myself and Richard Jones to act as BDFL-Delegates for metadata interoperability and pypi.python.org related aren't scaling adequately, so given Paul's recent delegation for PEP 470, and Donald handling PEP 503 directly, it seems like an opportune time to put something in writing about that.
For PyPA/distutils-sig specific PEPs, we've effectively adopted the following approach to assigning BDFL-Delegates in resolving PEPs 470 and 503:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
And translating the nominated roles to the folks currently filling them: "lead PyPI maintainer" = Donald Stufft; "lead CPython representative on distutils-sig" = me.
"PyPA core reviewer" isn't a term we've previously used, but I'm aiming to capture "has approval rights for pull requests to one or more of the PyPA maintained source code or documentation repos".
Some further details for the benefit of folks not aware of the
relevant history:
- a couple of years ago, we amended PEP 1 to give the "Discussions-To"
header some additional force for PEPs which don't directly affect CPython: """PEP review and resolution may also occur on a list other than python-dev (for example, distutils-sig for packaging related PEPs that don't immediately affect the standard library). In this case, the "Discussions-To" heading in the PEP will identify the appropriate alternative list where discussion, review and pronouncement on the PEP will occur."""
- we *didn't* update the section about assignment of BDFL-Delegates.
Instead, I received a general delegation for packaging metadata interoperability PEPs, and Richard Jones received one for pypi.python.org related PEPs
- Richard subsequently passed the latter delegation on to Donald,
since Donald had taken over as the lead maintainer for PyPI
The section in PEP 1 for CPython BDFL-Delegates reads as follows:
However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. =================================
This process can be appropriately described as "volunteering to be blamed" - if a PEP from a less experienced contributor subsequently proves to be a mistake, that's on the BDFL-Delegate for saying "Yes", not on the PEP author for proposing it. Mostly though, it's so there's someone to have the final say on the fiddly little details that go into getting from a general concept to an actual implementation, without getting mired down in design-by-committee on every incidental detail.
As PEP authors, we'll also often ask someone else specifically to volunteer as BDFL-Delegate, because we trust their judgement in relation to the topic at hand (e.g. I asked Martin von Löwis to be BDFL-Delegate for the original ensurepip PEP because I knew he was skeptical of the idea, so a design that passed muster with him was likely to have suitably addressed the ongoing maintainability concerns. Guido did something similar when he asked Mark Shannon to be BDFL-Delegate for PEP 484's gradual typing).
Regards, Nick.
P.S. It's becoming clear to me that I should probably write a companion PEP to PEP 1 that specifically describes distutils-sig's usage of the PEP process (and how that differs from the normal CPython processes), but hopefully this post provides sufficient clarification for now.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On September 5, 2015 at 7:13:18 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
On 6 Sep 2015 08:31, "Marcus Smith" wrote:
is this a response to other thread about how/where to store specs and
PEPs?
If not, what in this email are you responding to?
I believe Donald was suggesting we could just have a PyPA specific change proposal process hosted on packaging.python.org, rather than using a variant of the PEP process.
I don't want to do that though - PyPA/distutils-sig's authority *is* delegated from python-dev through the BDFL-Delegate and Discussions-To headers in the regular PEP process, and there are going to be some proposals affecting ensurepip and distutils that still fall under python-dev rather than distutils-sig.
Dealing with the PEP repo is currently more painful than it needs to be, but that's what the forge.python.org proposals aim to address.
I was yes, though I don't feel extremely strongly about it, but I do wonder if it wouldn't fit us better. I'll make my case here real quick, but unless others are interested in it I don't really feel strong enough to push for it.
We're currently using the PEP process, but we've had to bend the PEP rules several times in order to fit us. It's obvious the PEP process is designed primarily to handle changes to Python itself, even the BDFL-Delegate rules currently state you have to be a Python core developer and that you need permission from Guido for it. On top of that, almost all of the things we touch don't really fall under python-dev's authority. PyPI, pip, setuptools, bandersnatch, devpi, etc are external projects and only really distutils and ensurepip need python-dev's stamp of approval. In a way, we're already part way to the RFC process that rust uses through the interoperability-peps repo on Github. The primary differences would be that we manually copy things over to the Python PEPs repository and we don't really follow the rules for BDFL-Delegates, we just invent our own rules and it's sort of OK because nobody really cares.
It is kind of awkward to essentially have the "real" copy of the PEP live in Github and that's where all the work on it happens but then needing to manually copy things over. It makes it kind of annoying to work on things, especially since any typo change or the such requires additional work to keep the two copies in sync.
On the other hand, if we focused on a process that worked for us, instead of trying to shoe horn things into the PEP process we could optimize it for how we function. This could also include direct integration with packaging.python.org or something similar if we wanted to go down that road.
I don't know, I think we could have a better process if we did our own thing, so it's something to think about at least.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
yea, I like the idea of our own authoritative Pypa project for proposals, and maybe have it hold the final "Specs" we're talking about as well (and just have PyPUG link to them or whatever).
I *think* it would lower the bar for people considering getting involved with writing specs and enhancements.
"Oh, it's just a github project, and you do PRs... I can do that... let me start writing now..."
for ensurepip, yea, do PEPs, since it's in Python.
On Sat, Sep 5, 2015 at 4:49 PM, Donald Stufft donald@stufft.io wrote:
On September 5, 2015 at 7:13:18 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
On 6 Sep 2015 08:31, "Marcus Smith" wrote:
is this a response to other thread about how/where to store specs and
PEPs?
If not, what in this email are you responding to?
I believe Donald was suggesting we could just have a PyPA specific change proposal process hosted on packaging.python.org, rather than using a variant of the PEP process.
I don't want to do that though - PyPA/distutils-sig's authority *is* delegated from python-dev through the BDFL-Delegate and Discussions-To headers in the regular PEP process, and there are going to be some proposals affecting ensurepip and distutils that still fall under python-dev rather than distutils-sig.
Dealing with the PEP repo is currently more painful than it needs to be, but that's what the forge.python.org proposals aim to address.
I was yes, though I don't feel extremely strongly about it, but I do wonder if it wouldn't fit us better. I'll make my case here real quick, but unless others are interested in it I don't really feel strong enough to push for it.
We're currently using the PEP process, but we've had to bend the PEP rules several times in order to fit us. It's obvious the PEP process is designed primarily to handle changes to Python itself, even the BDFL-Delegate rules currently state you have to be a Python core developer and that you need permission from Guido for it. On top of that, almost all of the things we touch don't really fall under python-dev's authority. PyPI, pip, setuptools, bandersnatch, devpi, etc are external projects and only really distutils and ensurepip need python-dev's stamp of approval. In a way, we're already part way to the RFC process that rust uses through the interoperability-peps repo on Github. The primary differences would be that we manually copy things over to the Python PEPs repository and we don't really follow the rules for BDFL-Delegates, we just invent our own rules and it's sort of OK because nobody really cares.
It is kind of awkward to essentially have the "real" copy of the PEP live in Github and that's where all the work on it happens but then needing to manually copy things over. It makes it kind of annoying to work on things, especially since any typo change or the such requires additional work to keep the two copies in sync.
On the other hand, if we focused on a process that worked for us, instead of trying to shoe horn things into the PEP process we could optimize it for how we function. This could also include direct integration with packaging.python.org or something similar if we wanted to go down that road.
I don't know, I think we could have a better process if we did our own thing, so it's something to think about at least.
Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 6 Sep 2015 10:39, "Marcus Smith" qwcode@gmail.com wrote:
yea, I like the idea of our own authoritative Pypa project for proposals,
and maybe have it hold the final "Specs" we're talking about as well (and just have PyPUG link to them or whatever).
I *think* it would lower the bar for people considering getting involved
with writing specs and enhancements.
Brett Cannon set an October 31st deadline for the forge.python.org proofs-of-concept, so that aspect will be changing regardless (either to a PR-capable Kallithea, or GitHub+Phabricator)
Cheers, Nick.
ok, so this is PEP 474.... where's the activity for the forge idea happening? python-dev list?
On Sat, Sep 5, 2015 at 10:47 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 6 Sep 2015 10:39, "Marcus Smith" qwcode@gmail.com wrote:
yea, I like the idea of our own authoritative Pypa project for
proposals, and maybe have it hold the final "Specs" we're talking about as well (and just have PyPUG link to them or whatever).
I *think* it would lower the bar for people considering getting involved
with writing specs and enhancements.
Brett Cannon set an October 31st deadline for the forge.python.org proofs-of-concept, so that aspect will be changing regardless (either to a PR-capable Kallithea, or GitHub+Phabricator)
Cheers, Nick.
On 7 September 2015 at 01:43, Marcus Smith qwcode@gmail.com wrote:
ok, so this is PEP 474.... where's the activity for the forge idea happening? python-dev list?
While the final discussions will need to move to python-dev, the preliminary discussions are taking place on the core-workflow mailing list: https://mail.python.org/mailman/listinfo/core-workflow
My Kallithea based proposal is at https://www.python.org/dev/peps/pep-0474/ Donald's GitHub+Phabricator proposal is at https://www.python.org/dev/peps/pep-0481/
Brett has asked that the prototypes focus on the main CPython repo, even though we'd be moving the support repos first in any actual rollout: https://mail.python.org/pipermail/core-workflow/2015-August/000189.html
Cheers, Nick.
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
Nick: just be clear, if nobody nominates themselves, then you still remain (by default) the active delegate who's responsible for ruling on a Pypa-related PEP?
On 30 October 2015 at 16:27, Marcus Smith qwcode@gmail.com wrote:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
Nick: just be clear, if nobody nominates themselves, then you still remain (by default) the active delegate who's responsible for ruling on a Pypa-related PEP?
For anything PyPI related, it defaults to being Donald's call as lead maintainer, for other interoperability specs, it defaults to me.
Cheers, Nick.
On 10 November 2015 at 16:14, Nick Coghlan ncoghlan@gmail.com wrote:
On 30 October 2015 at 16:27, Marcus Smith qwcode@gmail.com wrote:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
Nick: just be clear, if nobody nominates themselves, then you still remain (by default) the active delegate who's responsible for ruling on a Pypa-related PEP?
For anything PyPI related, it defaults to being Donald's call as lead maintainer, for other interoperability specs, it defaults to me.
Although I'll also note that whenever Donald wants to handle an interoperability PEP himself (as with the dependency specifier one), I'm highly unlikely to object :)
Cheers, Nick.
On November 10, 2015 at 1:58:38 AM, Nick Coghlan (ncoghlan@gmail.com) wrote:
On 10 November 2015 at 16:14, Nick Coghlan wrote:
On 30 October 2015 at 16:27, Marcus Smith wrote:
================================= Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other PyPA core reviewer, the lead PyPI maintainer and the lead CPython representative on distutils-sig, then they will have the authority to approve (or reject) that PEP. =================================
Nick: just be clear, if nobody nominates themselves, then you still remain (by default) the active delegate who's responsible for ruling on a Pypa-related PEP?
For anything PyPI related, it defaults to being Donald's call as lead maintainer, for other interoperability specs, it defaults to me.
Although I'll also note that whenever Donald wants to handle an interoperability PEP himself (as with the dependency specifier one), I'm highly unlikely to object :)
And of course, it’s likely that a lot of PyPI PEPs will end up having someone other than myself as the BDFL-Delegate since it’s likely a fair number of them will be written by me heh.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-
Donald Stufft -
Marcus Smith -
Nick Coghlan