[Distutils] BDFL Delegates for distutils-sig PEPs

[Marcus Smith]

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 at stufft.io> wrote:

> On September 5, 2015 at 7:13:18 PM, Nick Coghlan (ncoghlan at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150905/f918947e/attachment.html>