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
>