On 6 Sep 2015 08:31, "Marcus Smith" <qwc...@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 <don...@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 (ncogh...@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 | ncogh...@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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig