Mailman 3 June 2018 - core-workflow

thanks.python webpage
by Pablo Galindo Salgado 13 Aug '18

13 Aug '18

Hi everyone, After talking with Victor Stinner on some ideas on how to encourage contributions to CPython and how to give more visibility to contributors (see Victor notes: http://pythondev.readthedocs.io/community.html), based on the https://thanks.rust-lang.org/ project (than in turn was based on http://contributors.rubyonrails.org/) I have created the following prototype in my daily commute time: https://thanks-python.herokuapp.com/ The project runs on Heroku at this moment, it fetches the latest changes from the git repository and updates every 30 minutes to get the latest information. You can click on any release to get the contributor names: Example: https://thanks-python.herokuapp.com/tag/v3.6.5 (the names are obtained from the commit messages) and you can in turn click any contributor name to get the list of commits: https://thanks-python.herokuapp.com/contributor/Mariatta You can also obtain a list of all contributors (all time contributors): https://thanks-python.herokuapp.com/all_time I want also to emphasize that this is just a very basic prototype made for evaluating the idea and the possible benefit that it has, but is functional :) The repo is located here: https://github.com/pablogsal/thanks-python At this point is a very simple flask app with a celery worker running in the background and a redis interface for celery and for storing the git data (so is very easy to bootstrap as the first thing it does when started is to clone the repo and fetch the data again). What are your opinions on the matter? P.S. Don't be to critic on my horrible html and web design skills ;) Regards from sunny London Pablo Galindo Salgado

3 3

Workflow for the PR?
by Stephane Wirtel 31 Jul '18

31 Jul '18

Hi all, I have read the workflow in the code of Bedevere (https://github.com/python/bedevere/blob/master/bedevere/stage.py#L7), and there is one thing I do not understand. Here is the PR - https://github.com/python/cpython/pull/5132 Steps: 1. label: "awaiting review" 2. I did the review and ask for some changes, so in this case, I don't approve the review. 3. the label has been changed to "awaiting core review" by Bedevere, but Why? I requested some changes and the PR is not in "awaiting changes" For me, normally, the label should be on "awaiting changes" and after a new commit/message from the author, the label should be "awaiting review" Thank you, Stéphane -- Stéphane Wirtel - https://wirtel.be - @matrixise

3 7

Improving CLA signing process
by Mariatta Wijaya 16 Jun '18

16 Jun '18

Currently, people wanting to contribute to projects like peps, devguide, core-workflow, bedevere, need to sign CLA, which requires a bpo account, and then they need to add their GitHub account to their bpo account. I find this quite complicated process and a barrier of entry. I think it will be great to have this process simplified. I think people should not need to have bpo account unless they're actually participating in the bug tracker for CPython. 1. Can we have people sign CLA and not require their bpo account? 2. Other big issue with bpo as CLA host is we don't have easy way that can let the-knights-who-say-ni update the label in the PR once the contributor has signed the CLA. I've brought this up at the language summit, as one of the necessary step before we can start using GitHub issues. (that is not yet decided, and this is not the thread to argue about it). But whether we are using GitHub issues or not, the current process needs improvement anyway. Mariatta ᐧ

6 9

Please reenable AppVeyor
by Victor Stinner 10 Jun '18

10 Jun '18

Hi, It seems like AppVeyor is stable again, and test_asyncio has been fixed, so I suggest to make AppVeyor required again on 2.7, 3.6, 3.7 and master branches. I just closed the issue of the most annoying test_asyncio failure, test_start_tls_server_1(): https://bugs.python.org/issue33694 Note: There are still two known test_asyncio random failures, but they seem to be rare. * https://bugs.python.org/issue31007 : test_pipe_handle * https://bugs.python.org/issue33531 : test_stdin_broken_pipe Victor

2 2

Time to switch off AppVeyor and start requiring VSTS for Windows?
by Brett Cannon 08 Jun '18

08 Jun '18

We had to turn off AppVeyor as a requirement today due to it not running any builds for the last 20 hours. Ned Deily suggested that since VSTS on at least Windows has stabilized that maybe we should switch off AppVeyor off entirely and make the Windows VSTS builder required. Since https://python.visualstudio.com/cpython/_build/index?context=mine&path=%5C&… shows the builder has been stable I would like to make this required for master today/tomorrow and then flip it on for the other 3.x branches on Friday if we don't see any instability. Any objections/opinions about doing this?

4 16

The current thinking/plans around VSTS as our CI
by Brett Cannon 02 Jun '18

02 Jun '18

Since both Paul Moore and Antoine Pitrou started to ask questions about a side comment I made about VSTS, I might as well start a discussion (Steve has also *just* emailed python-committers about this topic). Basically Steve Dower and I have been working directly with the VSTS team to improve their Python support. Along the way they have announced they are adding anonymous access to build logs which was always a major blocker for using it in open source. VSTS gave us early access to the anonymous access that they are launching along with 20 concurrent builders which is more than what we currently have on Travis and AppVeyor. At this point Steve has added the appropriate YAML files in the .vsts directory that control the build jobs so we can test out the integration and see what the performance is like. But based on what we have been seeing there will be no queue in getting PRs tested and that applies to Windows, macOS, and Linux (IOW better coverage and no more issues about performance or having to wait too long for CI to go green ;) . There is also other benefits like making at least Windows builds easier to release as signing those builds can now be automated. My expectation is that once we are convinced that the VSTS builds are passing consistently and everything is working as everyone wants for e.g. a week, we can plan to turn off Travis and AppVeyor for master and 3.x branches (no one wants to bother with trying to get 2.7 to work on this and we can simply continue to rely on Travis and AppVeyor as necessary for the next 18 months). I don't think we want to run multiple CIs indefinitely on the same branch as it does take time and effort to keep CI green on a provider since they all have their own quirks. I should also mention that this free access is not limited to just CPython and any project can get free accounts and credits now, you just have to talk to Steve about getting in on the anonymous access before it launches to the general public (I have no timeline on when that's happening).

10 21

core-workflow June 2018