[Distutils] Getting more momentum for pip

[Nick Coghlan]

On 7 Mar 2015 06:44, "Ian Cordasco" <graffatcolmingov at gmail.com> wrote:
> On Fri, Mar 6, 2015 at 5:55 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> >
> > The problem with discussing this sort of thing is that it's *very*
> > wide-ranging, and tends to produce huge rambling mega-threads[1] when
> > discussed in a public list. I'm not advocating any sort of private
> > cabal deciding the fate of pip, but maybe somewhere where the core
> > devs could agree their *own* opinions before having to face the public
> > wouldn't be such a bad thing. That's more or less what I'd expected
> > the pypa-dev list to be (as a parallel to the python-dev list) but it
> > doesn't feel like it's turned out that way, maybe because it doesn't
> > have a clear enough charter, or maybe because there's no obvious
> > *other* place to direct people to for off-topic posts (like
> > python-list is for python-dev).
>
> So sometimes private cabals need to be made in order to get a basis of
> what is reasonable. The WSGI working group tried to do that but that
> failed after about a week as more people tried to join the cabal and
> were allowed to do so.

It's worth noting that CPython didn't get public source control until it
was already around 9 years old (see the What's New for Python 2.0).

My understanding is also that the architecture & philosophy for CPython
were very much set by the original Python Labs crew (Guido, Tim Peters,
Barry Warsaw, Fred Drake) when they worked for Zope Corporation, just as
the direction of beaker-project.org is very much governed by what the core
team that works full time on it for Red Hat wants to do.

Confusing "open source" and even "open governance" with "no hierarchy" is a
common mistake, when the only essential requirement is that anyone is
welcome to observe and even suggest changes, whether to artefacts (open
source) or decision making processes (open governance).

The one thing that potential (and current!) contributors have to accept is
that the existing contributors are the ones that decide between "yes",
"no", and "maybe, let's discuss it some more", regardless of whether the
proposed change is to code, processes, or who has the authority to accept
changes.

All of which can be summarised in the phrase: "Those that do the work, make
the rules" :)

Cheers,
Nick.

>
> > Or maybe grand designs are a distraction in themselves, and none of
> > the core devs being interested in a PR means just that - not that they
> > don't have the time, or that the use case isn't valid, or anything
> > else. Just that they aren't interested, sorry.
> >
> > [1] Please, don't start a rambling mega-thread from *this* post :-)
> >
> > Paul
> >
> > PS I just spend way too long composing this email, and now I'm burned
> > out. Maybe my time would have been better spent commenting on a couple
> > of PRs...
>
> Go rest. These discussions can exhaust even the best rested of us.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150307/1d040a47/attachment.html>