On 5 March 2015 at 16:38, Marc Abramowitz <[email protected]> wrote: > Thoughts?
It seems to me that there is another point that delays progress on a certain proportion of PRs, specifically feature requests, namely that no-one really has that strong an opinion on whether they are a good idea or not. I know I've noticed a few requests recently where my reaction was essentially "I don't have a problem with this, but I don't care enough to actually add it" (it's not so much the mechanical aspect of merging the PR, but also the fact that you take on some level of "ownership" of the PR if you merge it). That's a much harder issue to resolve, as it revolves around having a clear roadmap for pip and a good understanding of scope - something we don't really have. But if we spend too long debating project direction and abstracts like that, we get even less done. Ian's point is also a good one. We get a lot of PRs for new features (which is where my point above applies) but far fewer for bug fixes. And there's also the problem with bug fixes that often the number of core devs with access to the affected platform is limited. (I try to cover Windows for Python 3, but I only have Linux access via setting up a VM, and I have no access to OSX[1], and my interest in Python 2 is limited at best. I'm sure the other devs have similar constraints). But unlike Ian, I think we *do* need to look at features. Things like separating the build and install phases, defining a supportable API for pip (whether the CLI or importable), supporting the in-development peps like Metadata 2.0, external hosting, wheel improvements etc etc, all need doing. The PEP process is the best way to handle this - if people on this list agree on a PEP, it's much easier to develop an implementation instead of just deciding on individual PRs in isolation. Paul. [1] Anyone want to buy me a mac? ;-) _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
