[Distutils] Getting more momentum for pip

[Paul Moore]

On 5 March 2015 at 18:33, Marcus Smith <qwcode at gmail.com> wrote:
>> An "issue before feature request PR" policy might help here.  Before
>> someone submits the feature request PR, have them open an issue for
>> discussion of the feature.  Recommend/Require that at least one core dev be
>> strongly in favor before giving approval to open the PR.  Automatically
>> close these issues without the approval after some amount of inactivity.
>> Automatically lose any feature request PRs that don't have an approved issue
>> associated with them.
>>
>> Put up an explanation of this policy, sympathy that it may cause
>> frustration, but that with limited time, devs must focus their efforts, etc.
>
>
> +1.  good idea.

Agreed, good idea.

We could probably also introduce some similar guidelines over issues /
bug reports. When reporting a bug, please provide clear instructions
on how to reproduce the bug, details of platform known to be affected,
etc. If that information isn't available, and the OP doesn't respond
after being prompted for the information, we'll close the bug after a
given period.

On a related note, maybe we need a better definition of what
platforms/configurations we support. For example, do we support using
pip with older versions of setuptools? ("Please upgrade setuptools and
confirm if the problem still exists, if it doesn't then that's the fix
and we'll close the issue") Platform-specific issues are the hardest
to deal with - if something comes up that only affects Gentoo Linux,
none of the core devs have any means of reproducing it without
creating a VM, working out how to install Gentoo, etc... "Not
supported" doesn't have to mean we won't help, but it might mean that
we label the issue somehow and need 3rd party help (either from the OP
or someone else) to progress the issue, and if nobody steps forward
after a certain amount of time, we close the issue (or just leave it
open - if it's labelled appropriately we can exclude it from any
measures we want to make of open issues we *expect* to work on).

Paul.