Re: [Distutils] BDFL Delegates for distutils-sig PEPs

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. Cheers, Nick.

On Sat, Sep 5, 2015 at 1:32 PM, Donald Stufft 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