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

[Nick Coghlan]

On 22 Jan 2017 11:26 pm, "Paul Moore"  wrote:


One question (and apologies if this has been discussed on another list
somewhere) - my biggest bottleneck is the sheer number of python-bugs
emails, and the difficulty of identifying ones I can contribute. Will
we be moving to the github issue tracker, and/or are there any likely
changes to more closely classify issues (ideally in a way that can be
handled via mail filters)?


The experts index in the developer guide is excellent for this - I *don't*
follow every new issue that gets filed, but I pay close attention to the
ones where I get added to the nosy list, and that's usually via the experts
index module and topic entries. It also gives me an incentive to keep my
entries in that file up to date (e.g. I was following tempfile when doing a
lot of filesystem manipulation tasks at work, but stopped doing so quite
some time ago).

We have some docs in the triager section of the guide about that, but
perhaps it would help to emphasise it more in the core dev section?

The move to GitHub will also make it easier to follow new PRs,
independently of the issue tracker.

Cheers,
Nick.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Ezio Melotti]

On Sat, Jan 21, 2017 at 9:51 PM, Brett Cannon  wrote:
> What I'm picking up from this is (as a gross oversimplification):
>
> * Victor _wants_ code reviews
> * Raymond thinks we _need_ code reviews
>
> So the common theme here regardless of whether you agree with Raymond or
> Victor's approach to development is that we are not getting enough code
> reviews to go around. To me that's what the systemic issue is that this
> email is bringing up.
>
> Now I think most of us don't think the solution to the lack of reviews is to
> lower our standard of what it takes to become a core developer (this doesn't
> mean we shouldn't do a better job of identifying potential candidates, just
> that we shouldn't give people commit privileges after a single patch like
> some projects do). To me that means we need to address why out of 79 core
> developers only 39 have a single commit over the past year, 30/79 have more
> than 12 commits over that same time scale, 15/79 people have more than 52
> commits, and 2/79 people have over 365 commits
> (https://github.com/python/cpython/graphs/contributors?from=2016-01-22=2017-01-21=c
> for the stats).
>
> Some of you have said you're waiting for the GitHub migration before you
> start contributing again, which I can understand (I'm going to be sending an
> email with an update on that after this email to python-dev &
> core-workflow). But for those that have not told me that I don't know what
> it will take to get you involved again.

I can tell you what drove me away:
1) real life got in the way, time is limited;
2) I spend the available time working on the bug tracker rather than
on core Python, since my time is likely more valuable if spent on bpo;
3) MLs are quite high traffic, and I gave up keeping up /for now/ [0]
(I have 6.8k unread mails from python-checkins, 460 from
python-issues, 320 from python-dev).  This also means that:
  a) if a bug related to one of the modules I maintained is opened, I
won't see it[1];
  b) if a message explicitly asks for my opinion/review, I won't see it[1];
4) the GitHub migration (first I was against, now I'm waiting for
everything to settle and then give it a try, in future I hope it will
become a reason to get me involved again);
5) the more time I spend away, the more difficult it becomes to follow
all the new features that get introduced.

As for what would get me involved again, for my case there's not much
else you can do -- I just need to find more free time, catch up with
development (mails, tools, features, etc) and then try to keep up.

Best Regards,
Ezio Melotti

[0]: FWIW one thing that helped me keeping the mail traffic low(er),
was following the weekly issues reports on python-dev, and adding
myself to nosy on the issues I cared about, rather than subscribing
and following the other mailing list (python-bugs-list and
new-bugs-announce).
I also used to keep an eye on #python-dev for new issues and replies,
and I wish more core-devs would hang around there, since it makes
communication (including asking for opinions/reviews) much faster.

[1]: Feel free to reach to me directly, either on IRC or via direct mail.

> For instance, not to pick on Andrew
> but he hasn't committed anything but he obviously still cares about the
> project. So what would it take to get Andrew to help review patches again so
> that the next time something involving random comes through he feels like
> taking a quick look?
>
> As I have said before, the reason I took on the GitHub migration is for us
> core developers. I want our workflow to be as easy as possible so that we
> can be as productive as possible. But the unspoken goal I have long-term is
> to get to the point that even dormant core devs want to contribute again,
> and to the point that everyone reviews a patch/month and more people
> reviewing a patch/week (although I'll take a patch/year to start). I want to
> get to the point that every person with commit privileges takes 30 minutes a
> month to help with reviews and that the majority of folks take 30 minutes a
> week to review (and please don't think this as a hard rule and if you don't
> the privileges go away, view this as an aspirational goal). Even if people
> who don't have time to review the kind of patches Victor is producing which
> triggered this thread, reviewing documentation patches can be done without
> deep knowledge of things and without taking much time. That way people who
> have time to review the bigger, more difficult patches can actually spend
> their time on those reviews and not worrying about patches fixing a spelling
> mistake or adding a new test to raise test coverage.
>
> All of this is so that I hope one day we get to the point where all patches
> require a review no matter who proposed the code change. Now I think we're
> quite a ways of from being there, but that's my moonshot goal for our
> workflow: that we have enough quality reviews coming in that we feel that
> even patches from fellow 

Re: [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  wrote:

> On 23 January 2017 at 19:31, Brett Cannon  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 .


>
> > 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
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Paul Moore]

On 23 January 2017 at 19:31, Brett Cannon  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).

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). 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.

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

Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Brett Cannon]

On Sun, 22 Jan 2017 at 14:26 Paul Moore  wrote:

> On 22 January 2017 at 21:59, Barry Warsaw  wrote:
> > On Jan 22, 2017, at 12:22 PM, Brian Curtin wrote:
> >
> >>I've been on the sidelines for a while myself for a number of reasons,
> >>but the shift to GitHub will pull me back in for sure, at least in
> >>terms of code review. I look forward to actually contributing code
> >>again soon, but easier tooling on reviews—rather, a shiny new one, as
> >>I'm aware of Reitveld—is enough of a carrot to bring me back in.
> >
> > I feel exactly the same way.  I'm very excited about the move to git and
> > GitHub and look forward to ramping my contributions back up.  Thank you
> Brett
> > and everyone else working so hard to make this as smooth and timely a
> > transition as possible.
>
> One question (and apologies if this has been discussed on another list
> somewhere) - my biggest bottleneck is the sheer number of python-bugs
> emails, and the difficulty of identifying ones I can contribute. Will
> we be moving to the github issue tracker, and/or are there any likely
> changes to more closely classify issues (ideally in a way that can be
> handled via mail filters)?


As Barry pointed out we are not moving the issue tracker. I thought about
it but I instantly got pushback on the idea and I only have so much time
and patience. :)


> Specifically, I'm interested in being able
> to restrict issue traffic by:
>
> * Pure Python, C, or "not code" (docs, etc).
> * Windows/Unix
> * Relevant stdlib module
>

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

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.


>
> (Or at least have some means of scanning issue emails to quickly spot
> which ones fall into which classification).
>

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).


>
> That's a long way beyond simply "switching to github which is a
> workflow I'm more familiar with" and while I hope github will help me
> to contribute more, I do think that ultimately the issue is simply
> that Python is a large and complex system, and people like me have
> limited time - and too much of it gets wasted playing "spot something
> I can work on", but that's inherent in the nature of a system this
> size.
>

Sure, but there are also things we can try to do to minimize the burden
(and anything that can be automated is best :) .

-Brett


>
> Paul
>
> PS I know there's searches and labels. But the "push" nature of email
> has its own benefits for me, so there's still a trade off there.
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Doug Hellmann]

Excerpts from Brett Cannon's message of 2017-01-21 19:51:48 +:
> What I'm picking up from this is (as a gross oversimplification):
> 
> * Victor _wants_ code reviews
> * Raymond thinks we _need_ code reviews
> 
> So the common theme here regardless of whether you agree with Raymond or
> Victor's approach to development is that we are not getting enough code
> reviews to go around. To me that's what the systemic issue is that this
> email is bringing up.
> 
> Now I think most of us don't think the solution to the lack of reviews is
> to lower our standard of what it takes to become a core developer (this
> doesn't mean we shouldn't do a better job of identifying potential
> candidates, just that we shouldn't give people commit privileges after a
> single patch like some projects do). To me that means we need to address
> why out of 79 core developers only 39 have a single commit over the past
> year, 30/79 have more than 12 commits over that same time scale, 15/79
> people have more than 52 commits, and 2/79 people have over 365 commits (
> https://github.com/python/cpython/graphs/contributors?from=2016-01-22=2017-01-21=c
> for
> the stats).
> 
> Some of you have said you're waiting for the GitHub migration before you
> start contributing again, which I can understand (I'm going to be sending
> an email with an update on that after this email to python-dev &
> core-workflow). But for those that have not told me that I don't know what
> it will take to get you involved again. For instance, not to pick on Andrew
> but he hasn't committed anything but he obviously still cares about the
> project. So what would it take to get Andrew to help review patches again
> so that the next time something involving random comes through he feels
> like taking a quick look?
> 
> As I have said before, the reason I took on the GitHub migration is for us
> core developers. I want our workflow to be as easy as possible so that we
> can be as productive as possible. But the unspoken goal I have long-term is
> to get to the point that even dormant core devs want to contribute again,
> and to the point that everyone reviews a patch/month and more people
> reviewing a patch/week (although I'll take a patch/year to start). I want
> to get to the point that every person with commit privileges takes 30
> minutes a month to help with reviews and that the majority of folks take 30
> minutes a week to review (and please don't think this as a hard rule and if
> you don't the privileges go away, view this as an aspirational goal). Even
> if people who don't have time to review the kind of patches Victor is
> producing which triggered this thread, reviewing documentation patches can
> be done without deep knowledge of things and without taking much time. That
> way people who have time to review the bigger, more difficult patches can
> actually spend their time on those reviews and not worrying about patches
> fixing a spelling mistake or adding a new test to raise test coverage.
> 
> All of this is so that I hope one day we get to the point where all patches
> require a review no matter who proposed the code change. Now I think we're
> quite a ways of from being there, but that's my moonshot goal for our
> workflow: that we have enough quality reviews coming in that we feel that
> even patches from fellow core developers is worth requiring the extra code
> check and disbursement of knowledge without feeling like a terrible drag on
> productivity.
> 
> Once the GitHub migration has occurred I'm planning to tackle our Misc/NEWS
> problem and then automate Misc/ACKS. After that, though, I hope we can take

I would be happy to help with both of those tasks. I have experience
with both within the OpenStack project.

And put me on the list of "waiting for github" contributors. I
should have more time freeing up in a couple of months as I change
some of my responsibilities at work. I would like to help with the
migration and eventually regular reviews.

Doug

> the time to have a hard look at what in our workflow prevents people from
> making even occasional code reviews so that everyone wants to help out
> again (and if any of this interests you then please subscribe to
> core-workflow).
> 
> On Fri, 20 Jan 2017 at 02:46 Victor Stinner 
> wrote:
> 
> > Hi,
> >
> > Raymond Hettinger used a regression that I introduced in the builtin
> > sorted() function (in Python 3.6.0) to give me his feedback on my
> > FASTCALL work, but also on Argument Clinic.
> >
> > Context: http://bugs.python.org/issue29327#msg285848
> >
> > Since the reported issues is wider than just FASTCALL, including how I
> > contribute to CPython, I decided to discuss the topic with a wider
> > audience. I continue the discussion on python-committers to get the
> > opinion of the other core developers.
> >
> > Sorry for my very long answer! I tried to answer to each issues
> > reported by Raymond.
> >
> > Inaccurate summary: I'm a strong supporter of