[Distutils] Getting more momentum for pip

[Donald Stufft]

> On Mar 5, 2015, at 3:11 PM, Ian Cordasco <graffatcolmingov at gmail.com> wrote:
> 
> 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.

Github has CONTRIBUTING.rst which is an obvious place to put something
like this. Giant mega PRs are certainly harder to merge than small PRs
but also important is the benefit of the PR itself. A small PR that doesn’t
seem to improve things much or is just shuffling around code is less
useful than a PR that reorganizes some of the code to be cleaner.

Sadly with how the code in pip is written, sometimes it’s just not
reasonable to make small PRs because things are not well factored and
changing things requires touching a lot of different areas. Those kinds of
PRs are OK as a last resort, but ideally the PR will be opened up early
on as a WIP and they should be attempted to be as small as possible
still.

> 
> 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?

Hosted services are ideal for this, though that limits things a bit,
but hosted services of OSS software is even better of course. There
are a number of bug trackers that can be configured to allow open
registration and so that anyone who registers can modify ticket states.

Maintaining things is easier than setting them up (I already maintain
stuff for the PSF, so adding more stuff isn’t that big of a deal) the
major thing is going through all the different solutions, figuring out
which ones best fit our needs, making sure it can be configured via
salt instead of via a UI, etc and making a proposal to actually switch
to it and what the fallout and work required to do that would be.

> 
> 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?

Assuming we can give someone permission to set a status on github PRs
without giving them push access or other access I would be perfectly
fine with a “third party CI” solution like that. We’d need to hash out
exact requirements but it’s certainly a possibility.

I’d like to point out again that if anyone knows go and can write a little
golang program that spins up a Windows Azure server, and runs a command
using winrm, any command even echo, we can give that to Travis to help
them get Windows support.

> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150305/5be56681/attachment.sig>