[Distutils] Getting more momentum for pip

[Ian Cordasco]

On Thu, Mar 5, 2015 at 1:55 PM, Marc Abramowitz <msabramo at gmail.com> wrote:
> Yeah my changes are quite trivial. And there is much more complex stuff that
> could be improved. IIRC, `pip/req/req_install.py` is the real behemoth. I
> remember feeling afraid to touch that thing. :)
>
> I do think this illustrates some of the problem though in that if those 3
> very simple PRs are not merged or closed, then I don't have a lot of faith
> that any more complex PR that I might submit would be worth the time
> investment.
>
> I feel like I'm somewhat conditioned to only submit small PRs to pip because
> they have the lowest risk (although also the lowest reward of course).

The lowest reward to whom? If it's a good change that fixes something
(regardless of the size that's a big reward to the project and its
users.

I'm also not going to go back in the thread to reply all of the
messages, but I want to be clear that I didn't mean every feature
should be rejected. Just that for a project as critical to an
ecosystem like Python's, rejecting features should be fairly easy to
do and very simple. If no current core developer wants to maintain it
or feels strongly about it, that should be closed. A nice, already
written, form explanation would probably antagonize contributors less
than a short reasoning that might come off curt. That said, you'll
always lose some contributors by closing their pull requests or by
trying to help them get it into a good state.

In my opinion, gigantic PRs that refactor things should be rejected
immediately. Those can almost certainly always be done in smaller,
easier to review, and easier to understand pull requests.
Mega-refactors that will take hours (or even days) to review that
modify all of the tests should be absolutely out of the question if
pip is going to come up with better guidelines. requests has received
a handful of them, and we've tried to coach those people (who are
often first-time contributors) into breaking it up but they always
leave, and the project has to realize that sometimes it's an
acceptable loss.

Having clear guidelines is great, they should be enforced and they
should be linked somewhere, like the top of the README.

Regarding empowering people to close, label, and triage issues is
going to be much harder. There are only two systems I can think of
that allow for this: Launchpad and Trac. Trac is Django's tracker (in
case people aren't aware) and Django has found a way to integrate it
with GitHub. We /could/ take that approach, but that leaves the
following questions:

- Who is going to maintain the server(s)?
- Who is going to provision them initially?
- What happens if those people (ideally it's more than just one
person) disappear? Will we have enough people to reduce the bus
factor?
- Will this ever become yet another thing that the core developers
have to spend time on instead of reviewing pull requests and fixing
bugs?

Regarding auto-closing, please don't do it. Especially for the ones
where someone didn't file a bug first, it may be the only way to
figure out what's going on?

And for CI, we need people who will help with the windows CI solution
on more than one front clearly. I think pyca/cryptography has OS X
builders on Travis, so we could probably add tests for that, but for
RHEL that's going to be much harder. I think this is where Marc's
reference to OpenStack fits in perfectly though. In OpenStack there's
a concept of third party CI. (There's a similar notion with the
buildbots for CPython.) The people who register those CI systems
maintain them but the project determines whether or not that system's
failing build should count against a change or not. GitHub allows for
multiple statuses to be set on a commit/PR from multiple services.
Thoughts?