[Distutils] Getting more momentum for pip

[Ian Cordasco]

On Thu, Mar 5, 2015 at 10:38 AM, Marc Abramowitz <msabramo at gmail.com> wrote:
> This post is meant to start a discussion on how to make sure that important
> PyPA projects like pip get enough eyes so that they can continually move
> forward. It is absolutely NOT meant to be critical of folks who volunteer
> their time to work on these projects, as I have the utmost respect for folks
> who do this often thankless work. And since the word "thankless" just popped
> into my head, let me say "thank you" right now to the folks who contribute
> to PyPA.
>
> I've noticed that when PRs are submitted to pip (by myself and by others),
> they often languish for a while and then sometimes become unmergeable
> because of conflicts.
>
> This makes me think that the folks who review the PRs are overburdened
> and/or the process needs a bit more structure (e.g.: each person thinks
> someone else is going to review the PR and so no one does it).
>
> So some ideas off the top of my head - please comment and/or add your own
> suggestions to the list:
>
> - Add more committers - this will ostensibly increase the number of folks
> reviewing so that the turnaround time is decreased. And takes some pressure
> off.
>
> - Obtain some kind of funding so that committers can be compensated for
> their work and don't feel as bad about spending time on it. These people
> have day jobs and families so maybe this would help; maybe not.
>
> - Introduce some bot or automation that periodically reminds about open PRs
> that are getting old or PRs that have become unmergeable, etc. Or maybe for
> each PR, it picks one or more persons who is responsible for reviewing that
> PR, so there is no ambiguity about who is responsible. The OpenStack folks
> have quite a bit of structure in their workflow (probably too much for PyPA
> projects which have less people working on them?), but perhaps there are
> some things that can be borrowed. In particular, changes need a certain
> amount of upvotes to be merged and reviewers usually request feedback from
> certain individuals.
>
> So I guess my suggestions boil down to:
>
> - Add more humans
> - Add more money to make humans more efficient
> - Add more computer automation
>
> #3 seems most appealing to me, but of course it requires humans to develop
> it in the first place, but at least it's an investment that could pay
> dividends.
>
> Thoughts?

Personally I value stability over a tendency to merge every PR. I know
you're not advocating that every PR be merged (or at least I hope
you're not), but the only way to add more core developers is to have
people who are already volunteering to review other people's pull
requests. "Core developer" is a title that is not so much a privilege
as it is a responsibility and it should only be given to those who are
already volunteering time to contribute to pip and other PyPA projects
through multiple efforts (e.g., reviewing other people's code - not
just sending their own, supporting the project either on
StackOverflow, irc, or somewhere else, etc.)

For the short time that I subscribed to pip notifications I noticed a
lot of PRs and a lot of pings but very little serious critical review.
Most PRs in that period of time seemed to be feature PRs and not bug
fixes. Personally, Bug Fixes are more important than Features and not
ever new feature deserves to be merged, in fact, I would say probably
more projects would do better by rejecting most new features.

OpenStack's workflow is incredibly different from most other projects
that aren't people's day jobs for a few reasons:

1. OpenStack is a globally distributed effort. Each project has
hundreds of contributors and most only have 5-10 core reviewers who
tend to be nominated only after a lot of sweat has been poured into a
project.
2. No one can commit directly to a repository.
3. There's a lot of automation around tests but there's also a lot of
ceremony in review
4. New features are strongly vetted through a blueprint and
specification process that more core reviewers contribute to but do
not drive (hence why people who are "core" on that process are called
drivers)
5. There's a much clearer review system in place where votes actually
matter and are aggregated
6. People (like myself) are literally paid to work on OpenStack. Few
people work on it in their free time except to keep their job
7. pip is (in my opinion) far more stable than OpenStack and I would
like to keep it that way. I know there are OpenStack Infrastructure
folks who monitor this list, but OpenStack continuously reaches into
private areas of projects and when those change, OpenStack tends to
get angry at upstream for not having backwards compatibility in
non-public APIs. pip on the other hand doesn't do that.

I'm sure Donald needs help. I don't think the right kind of help now
is adding more people who can merge things arbitrarily. I think the
right kind of help needs to be focused towards stability and we need a
better way of defining what new features belong in pip and what don't
to reduce the volume of pull requests that are deprioritized purely
because they're features that may or may not have been discussed with
PyPA cores beforehand.