Mailman 3 September 2019 - python-committers

Tooling built around historical record of core devs
by Brett Cannon 16 Sep '19

16 Sep '19

A couple months ago I generated a canonical, historical record of people who have been core developers at https://github.com/python/voters/blob/master/python-core.toml. The goal was for that list to feed into the devguide for the public record of who has been a core dev as well has to help calculate who has been active for voting purposes. Both are now done. https://devguide.python.org/developers/ has been updated to use a CSV generated from the python-core.toml file using code found in that repository. This should make maintaining that page in the devguide much easier and make it complete. In the voters repo I have also written code for validating the data in python-core.toml (which I hope to make into a GitHub action at some point to act as a check against PRs), a command to calculate who has authored or committed a change to CPython in the past two years to be classified as active, and code to generate a voter roll from that active contributor data. I am also hoping to help automate the adding/revoking permissions to at least GitHub, if not also b.p.o and discuss.python.org (this is why it's important you fill that information in python-core.toml). And in case anyone is curious, as of today there are currently 76 out of 166 people who have contributed in the past two years and thus are currently considered active.

2 2

Concerns about how we vote on new core developers
by Eric Snow 16 Sep '19

16 Sep '19

I have a growing concern I have about the impact of our current promotion process on aspiring core developers. I've opened a discussion thread about: https://discuss.python.org/t/concerns-about-how-we-vote-on-new-core-develop… -eric

1 0

Vote to promote Joannah Nanjekye as a core dev
by Victor Stinner 16 Sep '19

16 Sep '19

You have one week to vote at: https://discuss.python.org/t/vote-to-promote-joannah-nanjekye-as-a-core-dev… Victor

1 1

Bedevere will now re-request reviews when PR authors state they are ready for another review
by Brett Cannon 10 Sep '19

10 Sep '19

Thanks to Lysandros Nikolaou (https://github.com/lysnikolaou), I just landed https://github.com/python/bedevere/commit/6ea143bfe46527fdf0f475ff858af5004… at the Bloomberg core dev sprints which should make noticing PRs to re-review much easier. The outline is: 1. You, as a core dev, leave a review asking for changes 2. The PR author makes their changes and tells Bedevere "I have made the requested changes; please review again" (or uses the secret, funny phrase) 3. Bedevere will then re-request a review from the authors via GitHub's native mechanisms (i.e. same action as clicking the "Re-request review" button next to your review; it's the arrows in a circle icon) 4. The PR will then show up in your review queue at https://github.com/pulls/review-requested Before now you had to see the notification from Bedevere notifying you that the user believes their PR is ready for another review and you had to manually click the button to re-request your own review. Now you can rely on GitHub's review queue instead, making this part of our workflow less of a add-on and more integrated with GitHub overall. And because I just educated at least 3 people here at the Bloomberg sprints about how to easily find their PRs that they have in their review queue, there are links in the top black bar of GitHub for looking at issues and pull requests relevant to you. https://github.com/pulls will show you all your open pull requests and has a tab bar to also show you what PRs are assigned to you, mentioning you, or has a review request for you ( https://github.com/pulls/review-requested as mentioned before). There's a similar URL for issues at https://github.com/issues. And if you want to limit any of these views to just the Python organization, add "org:python" to the search that these views generate (you can also limit down to the repo).

2 1

Make AppVeyor CI non-mandatory during the CPython sprint?
by Victor Stinner 10 Sep '19

10 Sep '19

Hi, I see a high activity on pull requests on the CPython project, likely because of the CPython sprint. Sadly, the AppVeyor is still slow and still has only 2 jobs in parallel. Would it be possible to make the AppVeyor job non-mandatory to allow to merge a PR faster? If it's configurable per branch, it would be nice to do this change for 2.7, 3.7, 3.8 and master branches. I will keep an eye on buildbots to see if something bad happens :-) Victor

5 7

Dong-hee Na got the bug triage permission
by Victor Stinner 06 Sep '19

06 Sep '19

Hi, Dong-hee Na got the bug triage permission: https://github.com/python/core-workflow/issues/357 The bug triage permission now means being able to close issues at bugs.python.org, but also close pull requests and add labels on pull requests on GitHub (but not to merge a PR). I am mentoring him for 1 month to help him to handle these new responsibilities. He got 21 commits merged into master: https://github.com/python/cpython/commits?author=corona10 In a total of 36 PRs (including manual backports): https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Ac… He added: """ * I have a strong passion for the Python runtime and the standard library. This can be demonstrated by the enthusiastic activities of the project. (e.g Google grumpy, gpython, RustPython, pyston) * I would like to join the Python Triage Team to resolve minor issues and to help new contributors to land well with activities including code reviews. * I want to help Python interpreter projects based on other languages through the Python Triage membership team. (Reflects the latest implementation) """ Congrats Dong-hee Na ✨ 🍰 ✨! Victor

2 1