Mailman 3 September 2017 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

6 11

What is a CPython core developer?
by Victor Stinner 04 Oct '17

04 Oct '17

Hi, Recently, I asked their opinion to a few core developers about promoting some active contributors to core developers. It seems like we have no clear rules to decide if a contributor can be promoted or not. The problem is that sometimes, I am explicitly asked: What are the steps to become a core developer? Well, I'm not sure why some people really want to become core developers, but that's not question here :-) I started to list "responsabilities" (is it the correct word?) of a core developer. First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-)) I also see that some core developers are more conservative, want to reduce the risk of regressions, while some others are more on the "forgiveness" trend ("it's better to ask forgiveness than permission"). I think that it's perfectly normal and expected to have people on the two sides. The question is how to find a compromise in the middle. I identified the following CPython core developers responsabilities: * Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-) * Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews. * Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches. * For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-) * Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone. * Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc. * Something else? I don't expect this list to be complete. A vote for a promotion is always done on a case by case basis, mostly because it's really hard to be ready on *all* expected points. The discussion is more to estimate how far is the contributor in its learning, if it's enough, if more learning is needed, or if mentoring is needed. Maybe we should also formalize the mentoring for contributors identified as potential core developers. It can be an explicit step in the promotion process. Each last core developers who get promoted last year get a mentor if I recall correctly. What do you think? I started to write an article "What is a CPython core developer?" which describes even more things: https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_co… Victor

8 9

Hacktoberfest
by Mariatta Wijaya 04 Oct '17

04 Oct '17

Hi, October is hacktoberfest (https://hacktoberfest.digitalocean.com/) In the month of October, people can sign up and contribute to open source projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll earn a limited edition T-Shirt. If it's ok with everyone, I want to create "hacktoberfest" label and apply it to some of the open issues in the DevGuide and core-workflow repo. The purpose of the label is to make the repo discoverable, so it shows up as one of the participating projects: https://github.com/search?q=label%3Ahacktoberfest+state%3Aopen+type%3Aissue… Mariatta Wijaya

6 7

MSDN Subscriptions — First timers, renewals
by Brian Curtin 29 Sep '17

29 Sep '17

Hey everyone, If you've been waiting on a recent subscription renewal, my apologies—I dropped the ball on following up on some of them, but I'm getting things back in order with another request for renewals now that a few more are flowing in. If you are currently expired or within a month or so of a renewal, please send me the email address you use, your full name, and your mailing address. We haven't always needed mailing address for renewals, but they have been asking for it lately. If your expiration is a few months away, they seem to prefer we don't get too far ahead so email me directly when that time comes, or perhaps another one of these batches will match up. If you've never had a subscription but would like one, please send me the email address you use, your full name, and your mailing address. This will give you access to Microsoft's Developer Network, which includes access to things like Visual Studio and Windows licenses that we can use for working on Python. Thanks for everyone's work on Python! Brian

2 1

Can I get access to CPython's GitHub Webhook events?
by Mariatta Wijaya 26 Sep '17

26 Sep '17

Hi, As part of maintaining miss-islington, I think it would be great if I could see the GitHub webhook events for the CPython repo, just to make it easier for me to debug problems. Sometimes miss-islington doesn't work as expected, and the logs I get from heroku aren't too useful.. Not sure who in here can give me such access.. The webhook info is located in https://github.com/python/cpython/settings/hooks and to me this is a 404 right now. Thanks :) Mariatta Wijaya

2 1

Merging when assignee does not respond.
by Terry Reedy 24 Sep '17

24 Sep '17

https://bugs.python.org/issue30085 https://github.com/python/cpython/pull/1171 were submitted last April. Raymond assigned PR to himself, reviewed it in May. Contributor Sanket revised according to reviews, in my opinion adequately. Repeated pings on both issue and PR have not been answered. Can someone else merge this? tjr

2 1

Travis CI: macOS is now blocking -- remove macOS from Travis CI?
by Victor Stinner 23 Sep '17

23 Sep '17

Hi, Since today, it seems like the macOS task of a Travis CI job to validate a pull request hangs the whole job. Don't try to cancel the macOS job, or the whole job will be marked as failed! ... even if macOS is in the "Allowed Failure" section. I don't know the best way to "repair" such job. I use "restart job" which restarts all tasks, even the completed *and successful* Linux and doc jobs. I have PRs waiting for longer than 2 hours for Travis CI. The macOS job is seen as "queued". Yesterday, it was possible to merge a PR even if the macOS job was still queued (no started). I never wait for macOS, since, as I wrote, it can take longer than 1 hour. Moreover, macOS failures are not reported to the GitHub UI :-( (Hum, in fact, I'm not sure about that.) Maybe we should remove the pre-commit macOS task from the Travis CI config to focus on post-commit macOS buildbots? If we remove it, should we remove it from 2.7, 3.6 and master branches? We have 3 macOS buildbots: * x86 Tiger 3.x * x86-64 El Capitan 3.x * x86-64 Sierra 3.x All three are currently green ;-) In the last 3 months, the macOS task of Travis CI caused multiple issues :-/ Victor

6 12

Should I merge a PR that I approved if it was written by a different core developer?
by Victor Stinner 21 Sep '17

21 Sep '17

Hi, Before the GitHub era, in the old "Mercurial era", the unwritten rule was to not merge a patch written by a developer who has the commit bit, to not "steal" his/her work. The old workflow (patches attached to the bug tracker) didn't allow to easily keep the author. You had to find the author email and full name and specify it manually. Moreover, there was a written rule of using the name of the developer who actually pushed the commit, so the commiters took the responsability of any regression (reminder the old era with no pre-commit CI? ;-)). In the new Git era, the author and committer *can* be two different people. Examples with "git log --pretty=full": commit 9abee722d448c1c00c7d4e11ce242ec7b13e5c49 Author: Victor Stinner <victor.stinner(a)gmail.com> Commit: GitHub <noreply(a)github.com> commit 8f51bb436f8adfd139cad046b91cd462c7f27f6c (tag: v3.7.0a1) Author: Ned Deily <nad(a)python.org> Commit: Ned Deily <nad(a)python.org> commit 9b47af65375fab9318e88ccb061394a36c8c6c33 Author: svelankar <17737361+svelankar(a)users.noreply.github.com> Commit: Raymond Hettinger <rhettinger(a)users.noreply.github.com> My question is: is someone opposed that a core developer clicks on the [Merge] button for a PR proposed by a different core developer? IMHO having a committer different than the author is valuable since the responsability is now shared by two developers instead of single one. It's similar to the "Signed-Off" tags used by the Linux kernel, but the list is limited to a single Signed-Off :-) Well, the committer is usually seen as the most reponsible, but now we can complain to the author as well *if needed* :-D Victor

7 10

[RELEASE] Python 3.6.3rc1 and 3.7.0a1 are now available for testing and more
by Ned Deily 19 Sep '17

19 Sep '17

The Python build factories have been busy the last several weeks preparing our fall lineup of releases. Today we are happy to announce three additions: 3.6.3rc1, 3.7.0a1, and 3.3.7 final, which join last weekend's 2.7.14 and last month's 3.5.4 bug-fix releases and 3.4.7 security-fix update (https://www.python.org/downloads/). 1. Python 3.6.3rc1 is the first release candidate for Python 3.6.3, the next maintenance release of Python 3.6. While 3.6.3rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.3 is planned for final release on 2017-10-02 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.3rc1 and more information here: https://www.python.org/downloads/release/python-363rc1/ 2. Python 3.7.0a1 is the first of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.6.0a2, is planned for 2017-10-16. You can find Python 3.7.0a1 and more information here: https://www.python.org/downloads/release/python-370a1/ 3. Python 3.3.7 is also now available. It is a security-fix source-only release and is expected to be the final release of any kind for Python 3.3.x before it reaches end-of-life status on 2017-09-29, five years after its initial release. Because 3.3.x has long been in security-fix mode, 3.3.7 may no longer build correctly on all current operating system releases and some tests may fail. If you are still using Python 3.3.x, we **strongly** encourage you to upgrade now to a more recent, fully supported version of Python 3. You can find Python 3.3.7 here: https://www.python.org/downloads/release/python-337/ -- Ned Deily nad(a)python.org -- []

1 0

Reminder: snapshots and releases coming up in the next several days
by Ned Deily 19 Sep '17

19 Sep '17

Lots of releases coming up soon! 2017-09-16: - Python 2.7.14 final release 2017-09-18 1200 UTC cutoff: - Python 3.6.3 rc1 - Python 3.3.7 final release (following by retirement) If you know of any issues that you feel need to be addressed in these releases, please make sure there is an open issue on the bug tracker set to "release blocker". Also on 2017-09-18: - Python 3.7.0 alpha 1 This will be the first preview snapshot of 3.7.0. It's still very early in the development cycle for 3.7. The main purpose of early alpha releases is to exercise the build and release process and to make it easier for Windows and Macs users to help test. Many new features and build changes are yet to appear in subsequent releases prior to feature code cutoff on 2018-01-29 at 3.7.0b1. Thanks for your help! --Ned -- Ned Deily nad(a)python.org -- []

3 4