Mailman 3 June 2018 - python-committers

Missing In Action
by Victor Stinner June 19, 2018

June 19, 2018

Hi, Last months, we debated about the number of *active* core developers. The problem is that there are 3 lists and each has different numbers of core developers: 90 according to GitHub, 170 according to bugs.python.org. * https://github.com/orgs/python/teams/python-core/members * https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@p… * https://devguide.python.org/developers/ I propose to move inactive core developers to a new list (ex: "Inactive Core Developers") and remove their permission for security reasons. If the core developer shows up, they will just have to ask a GitHub administrator (like Brett Cannon) to be added again. My intent is to enhance security and better track of the current number of active core developers. In practice, it should only mean removing these inactive developers from the list of core developers on bugs.python.org. To make sure that a developer can become again a core developer, we should track that we dropped their priviledge. We can add new section in the devguide, near: https://devguide.python.org/developers/#permissions-dropped-on-request There are already two lists of inactive core developers in the devguide: "Permissions Dropped on Request" and "Permissions Dropped after Loss of Contact". I propose to start by removing all core developers who didn't migrate to GitHub yet, since it's a simple way to check if they are active since February 2017. I can work on a concrete list of developers, but it seems like it will take me some time. Some developers are cores according to bugs.python.org but I cannot find them in the devguide list. Some developers are no longer core devs according to devguide, but still core in bugs.python.org. There are some inconsistencies. Victor

15 31

Re: [python-committers] Results of Pablo's promotion votes: Pablo is promoted as a core dev!
by Victor Stinner June 19, 2018

June 19, 2018

> it sounds like you’ve signed up to mentor someone for three months. Under normal circumstances, the commit bit comes at the end of mentorship, not at the start. I am already mentoring him since January, it's not a start. I recall that I was scared of doing anything when I became a core dev. And I was right to be scared because I quickly broke the whole fleet of buildbots :-) As I new core, I would have been happy to have someone to guide me at the beginning :-) > Should we promote other mentees as well? I know there are a few who have been deliberately pursuing this recognition (as they attended the language summit and/or were specifically requested to attend the core sprint by their mentors). Yes please! The end of a dev cycle (3.7) is a good opportunity for that. Victor > > > > Top-posted from my Windows 10 phone > > > > From: Victor Stinner > Sent: Tuesday, June 19, 2018 10:44 > To: python-committers > Subject: [python-committers] Results of Pablo's promotion votes: Pablo ispromoted as a core dev! > > > > Hi, > > > > The result of the vote to to promote Pablo Salingo Salgado as core developer > > after one week is positive: I declare that Pablo is now a core developer, > > congrats! I will follow the usual process to actually make him a core dev, > > and ask him to write a short introduction email to this list. > > > > But I also noted that Pablo lacks experience to be fully autonomous on merging > > pull requests, so I also requires that Pablo will have to be strictly mentored > > by me for 3 months. By strict, I mean that Pablo will have to ask me to > > merge any pull request. This strict mentoring may be extended depending on > > Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to > > blame me directly if anything goes wrong :-) > > > > Giving more responsibilities to Pablo is part of the learning process. > > Reviewing as a core developer is different than a review as a contributor: core > > developers are expected to actually merge a pull request once they approve the > > change. Merging a pull request is a big responsibility and an investment in > > the long-term, because the committer is expected to fix regressions and issues > > related to this change for next months, if not next years. > > > > Note: Cheryl Sabella has also been identified as an active contributor who may > > be promoted as well. I am already discussing with her about that for 1 month, > > but last month, Cheryl chose to wait. I will keep you in touch ;-) > > > > Vote results. > > > > Promote (+1): 8 votes > > > > * Victor Stinner > > * Terry Reedy > > * Carol Willing > > * Gregory P. Smith ("+0.5") > > * Eric Snow > > * Brett Cannon > > * Nathaniel Smith > > * Antoine Pitrou ("+0.5") > > > > Wait (-1): 1 vote > > > > * Berker Peksağ > > > > Neutral (0): 1 vote > > > > * Serhiy Storchaka ("-0") > > > > Victor > > _______________________________________________ > > python-committers mailing list > > python-committers(a)python.org > > https://mail.python.org/mailman/listinfo/python-committers > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > >

1 0

Re: [python-committers] Results of Pablo's promotion votes: Pablo ispromoted as a core dev!
by Guido van Rossum June 19, 2018

June 19, 2018

I think we should give the mentors a choice in this. Victor has chosen to do it this way for Pablo. I don't know who (if anyone) is mentoring Cheryl. I think Eric Snow is mentoring Emily (I am too, but my mentoring is not very hands-on, and we only chat once every 3 weeks at most.) On Tue, Jun 19, 2018 at 1:10 PM Steve Dower <steve.dower(a)python.org> wrote: > Not trying to dispute the result (I’d have posted earlier if I was really > concerned), but it sounds like you’ve signed up to mentor someone for three > months. Under normal circumstances, the commit bit comes at the end of > mentorship, not at the start. > > > > Should we promote other mentees as well? I know there are a few who have > been deliberately pursuing this recognition (as they attended the language > summit and/or were specifically requested to attend the core sprint by > their mentors). > > > > Top-posted from my Windows 10 phone > > > > *From: *Victor Stinner <vstinner(a)redhat.com> > *Sent: *Tuesday, June 19, 2018 10:44 > *To: *python-committers <python-committers(a)python.org> > *Subject: *[python-committers] Results of Pablo's promotion votes: Pablo > ispromoted as a core dev! > > > > Hi, > > > > The result of the vote to to promote Pablo Salingo Salgado as core > developer > > after one week is positive: I declare that Pablo is now a core developer, > > congrats! I will follow the usual process to actually make him a core dev, > > and ask him to write a short introduction email to this list. > > > > But I also noted that Pablo lacks experience to be fully autonomous on > merging > > pull requests, so I also requires that Pablo will have to be strictly > mentored > > by me for 3 months. By strict, I mean that Pablo will have to ask me to > > merge any pull request. This strict mentoring may be extended depending on > > Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to > > blame me directly if anything goes wrong :-) > > > > Giving more responsibilities to Pablo is part of the learning process. > > Reviewing as a core developer is different than a review as a contributor: > core > > developers are expected to actually merge a pull request once they approve > the > > change. Merging a pull request is a big responsibility and an investment in > > the long-term, because the committer is expected to fix regressions and > issues > > related to this change for next months, if not next years. > > > > Note: Cheryl Sabella has also been identified as an active contributor who > may > > be promoted as well. I am already discussing with her about that for 1 > month, > > but last month, Cheryl chose to wait. I will keep you in touch ;-) > > > > Vote results. > > > > Promote (+1): 8 votes > > > > * Victor Stinner > > * Terry Reedy > > * Carol Willing > > * Gregory P. Smith ("+0.5") > > * Eric Snow > > * Brett Cannon > > * Nathaniel Smith > > * Antoine Pitrou ("+0.5") > > > > Wait (-1): 1 vote > > > > * Berker Peksağ > > > > Neutral (0): 1 vote > > > > * Serhiy Storchaka ("-0") > > > > Victor > > _______________________________________________ > > python-committers mailing list > > python-committers(a)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(a)python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)

1 0

Maintenance Tasks
by Victor Stinner June 18, 2018

June 18, 2018

Hi, At FOSDEM (last February), I saw an interesting talk by VM (Vicky) Brasseur: "Passing the Baton: Succession planning for FOSS leadership" She explains that the maintenance of a project should be splited into small tasks, and that each task should be done by at least two people. Why at least two, and not only one? Well, sometimes you may want to take holiday, one of your family member may become sick, or maybe you are simply bored and wants to do something else. You may have heard about the "bus factor", but I dislike this name because it sounds like a very unlikely event, whereas people leaving for whatever reason is common. It's also about documenting what you are doing to be able to pass the task to someone else. What should be documented? Well, here is where the second player matters: document enough until someone else is autonomous on the task. What are Python maintenance tasks? I identified the following tasks: http://pythondev.readthedocs.io/maintenance_tasks.html Copy of my list: * `Review and merge pull requests <https://github.com/python/cpython/pulls>`_. The merge action is restricted to core developers. Maintainers: active core developers (June 2018: around 34 core devs). * `Bug triage <https://bugs.python.org/>`_: closing a bug requires the bug triage permission. Maintainers: active core developers. * `Check for buildbot failures <https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/>`_: Read logs of each buildbot failure, check if the failure is known. If the failure is known, maybe mention the new failure in the existing bug. Otherwise, open a new bug. Then reply to the email with a link to the bug. Maintainers: Victor Stinner, Pablo Salingo Salgado. * Run bugs.python.org: fix bugs, deploy new version. See the `meta bug tracker <http://psf.upfronthosting.co.za/roundup/meta/>`_ for bugs of bugs.python.org itself (not for Python bugs). Roundup is going to be deployed in a Docker container on OpenShift. Maintainers: Ezio Melotti, Brett Cannon, Maciej Szulik. * `Run pythontest.net <http://www.pythontest.net/>`_. Maintainers: ? * Run GitHub bots. Maintainers: Brett Cannon and Mariatta Wijaya. * Update vendored external libraries. Maintainers: ? * Update unicodedata on new Unicode release. Latest update (Unicode 11.0): https://bugs.python.org/issue33778. Maintainer: Benajamin Peterson. I likely forget many tasks, since "maintenance" is a large topic and there are some tasks that are only be done rarely (like releases?). By the way, I also started to list known administrators. Some actions require administrators who are the only ones allowed to do actions. * Mailing lists: create a new mailing list. Maintainer: "postmaster" (who is the current postmaster?). * Bug tracker: give "bug triage permission". Administrators: Ezio Melotti, Ned Deily(?), R. David Murray. * GitHub cpython: add new core developers. Administrators: Brett Cannon, Ned Deily, others(?). I chose to start discussing maintenance tasks with core developers only (python-committers mailing list) since many tasks are reserved to (or at least currently done by) core developers. And I'm not sure that the concept of "maintenance tasks" makes sense, so I prefer to start discussing it with smaller audience :-) Note: The talk title is "Passing the Baton: Succession planning for FOSS leadership", but I don't ask here your BDFL to pass the baton ;-) I'm talking about the rest of talk. Victor

3 3

CI problem on old pull request
by Xiang Zhang June 15, 2018

June 15, 2018

I have just encountered a problem in PR1958. The appveyor CI prevents me from merging it. I can't see no way to disabling it or rerunning it, no details link. And is it possible to apply our new CIs, like vsts to it now? Regards Xiang Zhang

2 2

[RELEASE] Python 3.7.0rc1 and 3.6.6rc1 are now available
by Ned Deily June 12, 2018

June 12, 2018

Python 3.7.0rc1 and 3.6.6rc1 are now available. 3.7.0rc1 is the final planned release preview of Python 3.7, the next feature release of Python. 3.6.6rc1 is the the release preview of the next maintenance release of Python 3.6, the current release of Python. Assuming no critical problems are found prior to *2018-06-27*, the scheduled release dates for 3.7.0 and 3.6.6, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new features and bug fixes in 3.7.0 and 3.6.6 and to prepare your projects to support them. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant will become the default version when 3.7.0 releases. Check it out! You can find these releases and more information here: https://www.python.org/downloads/release/python-370rc1/ https://www.python.org/downloads/release/python-366rc1/ -- Ned Deily nad(a)python.org -- []

1 0

3.7.0rc1 and 3.6.6rc1 now tagged - on to final!
by Ned Deily June 12, 2018

June 12, 2018

An update: 3.7.0rc1 and 3.6.6rc1 are now tagged and we now move on to the final stages for 3.7.0 and for 3.6.6. The source code has been shipped to our factory (in a tariff-free zone!) where the elves will produce the final bits for the release. They promise to be done soon so stay tuned for the release announcements later today. In the meantime, the 3.7 and 3.6 branches in the cpython repo are open for merges. As of the rc1 cutoffs (tags v3.7.0rc1 and v3.6.6rc1 in the cpython repo), expect merges to 3.7 to appear in 3.7.1 and merges to 3.6 to appear in 3.6.7. Please continue to treat the 3.7 branch as if it were already released and in maintenance mode. Please continue to pay attention to CI test failures and buildbot test failures and see if you can help resolve them. If you find something that may affect either final release, please make sure to open a new issue on bugs.python.org, or update an existing issue, and set the priority to "release blocker". As always, improving the documentation never ceases so keep those updates coming in. Prior to 3.7.0 final and 3.6.6 final, I will review doc changes that have been merged and consider cherry-picking them into the release materials. By the way, don't be fooled: if you build Python from the 3.7 branch at the moment, the version will be "3.7.0rc1+" but changes merged will be in 3.7.1; similarly for 3.6. The clock is now ticking: 15 days until the final releases. Please do what you can to encourage exposure and testing by ourselves and our downstream users. Once again, I want to thank everyone who has been involved so far in helping us through the 3.7 endgame and who have given up their personal time to work on making Python better. I remain deeply grateful. --Ned Upcoming dates: - 2018-06-27 3.7.0 final !!! and 3.6.6 final !! - 2018-07-xx 3.7.1 - 2018-09-xx 3.6.7 -- Ned Deily nad(a)python.org -- []

1 0

3.7.0rc1 and 3.6.6rc happening later today!
by Ned Deily June 11, 2018

June 11, 2018

Short and sweet: thanks to a *lot* of work by a lot of people, we appear to be about ready to finally tag and manufacture the 3.7.0 release candidate! At the moment, we have no "release blocker" or "deferred blocker" issues open for 3.7 - a first! We also now have 21 out of 22 3.7 "production" buildbots consistently green or occasionally pink (meaning successful test retry) - also quite an accomplishment. (Only the 3.7 AIX PPC64 buildbot remains red but, since we really only support AIX on a "best effort" basis, we are not going to further delay 3.7.0 for it.) We have also had to make some tough decisions and defer some features to 3.8 and a few more complex bug resolutions to 2.7.1 or later. And releasing the "bonus beta", 3.7.0b5, resulted in some good feedback and squashing a few more issues. As you may recall, the most recently updated schedule calls for both 3.7.0rc1 and 3.6.6rc1 to be produced today, 2018-06-11, with the finals coming about two weeks later on 2018-06-27. I plan to start on 3.6.6rc1 in about 12 hours (around 22:00 UTC) with 3.7.0rc1 to follow soon thereafter. Feel free to use the remaining time to merge any last-minute documentation updates or minor bug fixes - but please do not break anything! When in doubt, ask. (I will be off-line for the next 8 hours or so.) After 3.7.0rc1 cutoff, new 3.7 merges will appear in 3.7.1, which should appear sometime next month (by the end of 2018-07). Likewise, new 3.6 merges will next appear in 3.6.7rc1, by the end of 2018-09. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. As always, if you think you may have found a critical problem at any time in either release candidate, please open (or reuse) an issue on bugs.python.org and mark it as "release blocker" priority. 3.7.0: here we come, thanks to you! --Ned -- Ned Deily nad(a)python.org -- []

1 0

b.p.o. status and resolution permissions
by Tal Einat June 11, 2018

June 11, 2018

Hi, I'm a (somewhat) new core-dev and have begun working on various issues. I don't have permission to change issue status and resolution on b.p.o. It seems at this point that is holding things back and making more work for others. I will be extra careful and only change those when I'm very sure it is appropriate. Can the necessary permission bits be flipped? - Tal Einat

2 1

Turning off AppVeyor as required
by Brett Cannon June 10, 2018

June 10, 2018

Victor noticed that AppVeyor stopped building about 19 hours ago, leading to it blocking all open PRs. I have gone ahead and switched off requiring AppVeyor for now, so please pay attention to at least the Windows VSTS status check to make sure you're not breaking Windows by accident.

4 9