On Thu, Mar 5, 2015 at 10:38 AM, Marc Abramowitz <[email protected]> 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. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
