[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 changeproposal process hosted on packaging.python.org, rather than using avariant 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-Toheaders in the regular PEP process, and there are going to be someproposals affecting ensurepip and distutils that still fall underpython-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 andpackaging using PEPs.

On September 4, 2015 at 11:42:21 PM, Nick Coghlan (ncoghlan at gmail.com)

wrote:

We've got to a point where the original standing delegations to myselfand Richard Jones to act as BDFL-Delegates for metadatainteroperability and pypi.python.org related aren't scalingadequately, so given Paul's recent delegation for PEP 470, and Donaldhandling PEP 503 directly, it seems like an opportune time to putsomething in writing about that.

=================================Whenever a new PEP is put forward on distutils-sig, any PyPA corereviewer that believes they are suitably experienced to make the finaldecision 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 theother PyPA core reviewer, the lead PyPI maintainer and the leadCPython representative on distutils-sig, then they will have theauthority to approve (or reject) that PEP.=================================

"PyPA core reviewer" isn't a term we've previously used, but I'maiming to capture "has approval rights for pull requests to one ormore 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 affectCPython: """PEP review and resolution may also occur on a list otherthan python-dev (for example, distutils-sig for packaging related PEPsthat don't immediately affect the standard library). In this case, the"Discussions-To" heading in the PEP will identify the appropriatealternative list where discussion, review and pronouncement on the PEPwill occur."""

* we *didn't* update the section about assignment of BDFL-Delegates.Instead, I received a general delegation for packaging metadatainteroperability PEPs, and Richard Jones received one forpypi.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 thatbelieves they are suitably experienced to make the final decision onthat PEP may offer to serve as the BDFL's delegate (or "PEP czar") forthat PEP. If their self-nomination is accepted by the other coredevelopers and the BDFL, then they will have the authority to approve(or reject) that PEP.=================================

This process can be appropriately described as "volunteering to beblamed" - if a PEP from a less experienced contributor subsequentlyproves 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'ssomeone to have the final say on the fiddly little details that gointo getting from a general concept to an actual implementation,without getting mired down in design-by-committee on every incidentaldetail.

As PEP authors, we'll also often ask someone else specifically tovolunteer as BDFL-Delegate, because we trust their judgement inrelation to the topic at hand (e.g. I asked Martin von L?wis to beBDFL-Delegate for the original ensurepip PEP because I knew he wasskeptical of the idea, so a design that passed muster with him waslikely to have suitably addressed the ongoing maintainabilityconcerns. Guido did something similar when he asked Mark Shannon to beBDFL-Delegate for PEP 484's gradual typing).

Regards,Nick.

P.S. It's becoming clear to me that I should probably write acompanion PEP to PEP 1 that specifically describes distutils-sig'susage of the PEP process (and how that differs from the normal CPythonprocesses), but hopefully this post provides sufficient clarificationfor now.