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