[python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Brett Cannon]

On Mon, 23 Jan 2017 at 11:50 Paul Moore <p.f.moore at gmail.com> wrote:

> On 23 January 2017 at 19:31, Brett Cannon <brett at python.org> wrote:
> > Do you want this to search issues or PRs by? Since the migration has not
> > happened yet there isn't any emerged practice yet of what will be
> labeled on
> > PRs and what will be kept on bpo (e.g. we will more than likely label
> what
> > versions of Python a PR should be applied to, but should we also add the
> > type of labels you mention above?).
>
> Hmm, issues and PRs on separate trackers? That might be interesting...
> (Although I'm sure you've thought it through and it'll be fine).
>

You can look at the test issue at https://bugs.python.org/issue2771 to see
what's there so far (specifically the Pull Requests section and the latest
PR listed there).


>
> I think the real issue here is that I really don't work well with
> systems where I have to go and look for stuff (I get distracted, or
> don't bother). Email is a huge win for me because I'm always looking
> at it, so things arriving by email get my attention. But of course,
> the converse of that is that too *much* traffic swamps me and I just
> start ignoring that folder (which is basically what happens with
> "Python bugs" and "Python checkins"). So I need to manage that, and
> bpo traffic is far away the highest-traffic thing I receive, so I
> haven't really evolved strategies for dealing well with that level of
> traffic.
>
> > Someone could also write a bot to help with this, e.g. automatically add
> > people to a PR for a review if a module mentioned in
> > https://cpython-devguide.readthedocs.io/en/latest/experts.html#stdlib
> is a
> > part of the PR.
>
> If PRs will come on github, I guess that as a member of the python-dev
> group I'll get the emails by default (like with pip, or other projects
> I contribute to).


You will need to have email notifications turned on with GitHub and watch
the cpython repository once we migrate. I think that will be enough if you
want it through GitHub.


> I'd probably just start by seeing how well skimming
> those emails would work (I imagine traffic on actual PRs would be
> notably less than on bugs as a whole).
>
> The trouble is, it's not really the experts list that matters to me. I
> get Windows issues from bpo at the moment, and while I'm interested in
> most of them, I don't often have much to contribute in terms of actual
> code reviews (because they tend to be C issues). I've no idea what
> facilities github has for anything in between "get everything" and
> "get nothing except what I subscribe to explicitly" as I've never yet
> needed to use anything but the former. And while a custom bot might be
> interesting, it's not going to pick up the sorts of things I get by
> skimming stuff.
>

You could try training a deep neural network to pick up on the things you
care about <half-wink>.


>
> > As Barry said, you can always follow new-bugs-announce or have a saved
> > search on bpo that sorts open issues by creation date and you check that
> > regularly (I do the latter and look at issues created the day previously
> and
> > just glance at their titles to decide if I should have a look).
>
> new-bugs-announce might be a better list for me than the full bpo
> stream. I might try that. IIRC, I joined the bpo and python checkins
> lists because the "guidelines for new core devs" said I should. Maybe
> there should be a qualification in there that the traffic is high, and
> if you have limited time, lower-traffic options might be better (or
> maybe there is and I ignored it :-))?
>

It actually says you can choose:
https://cpython-devguide.readthedocs.io/en/latest/coredev.html?highlight=new-bugs-announce#mailing-lists

-Brett


>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170123/04cd6022/attachment-0001.html>