Mailman 3 May 2018 - python-committers

Quick reminder: please don't push long-lived dev branches to the CPython repo
by Brett Cannon 28 May '18

28 May '18

If you create a dev branch that is going to live for less than 24 hours because you edited some typo in the docs or something through GitHub's UI, then that's fine. But long-lived dev branches should be done in one's personal fork. This is for two reasons: one is so that others don't inadvertently download your dev branch when they do a `git pull` (and because people often forget to do `git pull --prune`), and two because it eats up our CI (which is especially precious while we are still on AppVeyor and the turn-around time there is so long).

3 3

Re: [python-committers] A different way to focus discussions
by Barry Warsaw 24 May '18

24 May '18

[I think my other response got dropped, so apologies for any duplicates] Guido van Rossum wrote: > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. I don't think I'd want to see tons of new PEP repos under the current `python` organization. Maybe we should create a new organization for this experiment? Also, since non-core devs can and do create PEPs, the permission management will be different than the normal repos. Clearly the PEP authors should be owners of the individual repos, but they should probably also decide how merges happen, and who else can contribute to their repo. It also means that PEP editors probably have an additional responsibility to create the PEP repo. PEP 1's Discussions-To header can probably be co-opted for the URL to the GH repo. Right now, that field is described as an email address, but it would be appropriate IMHO to also allow a URL for discussions. > Thoughts? (We can dogfood this proposal too, if there's interest. :-) I don't know whether this will help focus rambling PEP discussions. I personally don't love the linearity of GH comments. Threading is useful! OTOH, it seems like a low-cost experiment to try so if there's a volunteer who wants to be the guinea pig, I'm fine with it. -Barry

5 9

Re: [python-committers] A different way to focus discussions
by Barry Warsaw 24 May '18

24 May '18

On May 22, 2018, at 12:44, Guido van Rossum <guido(a)python.org> wrote: > > Hm, what's the cost of those extra repos? As long as they have consistent names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a quota of repos per org? I think there is a quota for non-paying organizations, but I’m not sure. I was just thinking about clutter on https://github.com/python but maybe it won’t be so bad with… > I was thinking of a workflow where the pep author initially creates the repo under their own username and directs discussion there. Then when their PEP is accepted (or rejected!) they can donate their repo to the python org. I know such a thing is possible (we did it for the mypy and typeshed repos). … +1! > Ironically for me GitHub is less linear than email. It's easier to ask people to open a new issue than it is to ask them to start a new thread. So e.g. if a discussion starts about a survey of feature X in various languages, when it veers off into a tutorial for a specific language that could be a separate issue, and the meta-discussion on how the list of languages should be selected could be made another issue. I see what you’re saying. Yes, that could work if the PEP author is really diligent about shunting detours into new issues. I’ve just found that within PRs or issues, the linearity can be quite difficult to follow. (FWIW, IMHO, GitLab does better here, but that’s besides the point.) > I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a separate repo, he's just created a PR for the peps repo IIUC). I hope Nick will also volunteer PEP 577 for this. +1 -Barry

2 1

Re: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!
by Ned Deily 24 May '18

24 May '18

On May 24, 2018, at 07:26, Victor Stinner <vstinner(a)redhat.com> wrote: > 2018-05-24 9:23 GMT+02:00 Ned Deily <nad(a)python.org>: >> Any merges to the 3.7 branch after >> that will be released in 3.7.1 which we tentatively are planning to >> ship sometime before the end of July (< 2018-07-31). > I recall that Python 3.6.0 was full of bugs, some functions like > os.waitpid() on Windows (if I recall correctly) were completely > broken. > > We can do our best to test as much as possible, hope that more and > more people use the "nightly" Python version to run their CI, but we > always miss bugs. We always get the most testers when the final x.y.0 > version is released. > > Why waiting two months to release bugfixes? We're not planning on waiting two months. First, 3.7.0 final is not planned to release until 2018-06-15; if necessary, there could be one or more emergency bug fixes in it. Second, "before the end of July (< 2018-07-31)" does not mean we have to wait until the end of July. If necessary, it could be near the beginning of the month, so closer to two weeks after the release. Right now, our focus should be on getting high-quality 3.7.0rc1 and 3.7.0 final releases out there to our users and then we can focus on what comes next. Getting close! -- Ned Deily nad(a)python.org -- []

1 0

Bring back Travis & AppVeyor, make VSTS non-blocking
by Gregory P. Smith 18 May '18

18 May '18

VSTS is clearly not yet a stable continuous integration platform. It needs to be made non-blocking, and AppVeyor and Travis need to be brought back! Examples: https://github.com/python/cpython/pull/6938#issuecomment-389908094 Windows broke - https://python.visualstudio.com/cpython/_build?buildId=522 https://github.com/python/cpython/pull/6939 Linux broke - https://python.visualstudio.com/cpython/_build?buildId=523 This was on a documentation-only change. We cannot be changing to new PR-merge-blocking continuous integration services at this point during a release cycle. This is preventing changes from making it in. -gps

3 3

Can I just rerun a test on AppVeyor?
by Terry Reedy 17 May '18

17 May '18

I can restart a test on just Travis when AppVeyor (and now MSTS) all passed. But for the last few hours, test_async has failed 1/4 to 1/3 of the runs. This means that test_async failed twice, so I suspect that it actually fails about half the time. A connection error seems to be the main culprit. I could not find a rebuild button on the AppVeyor page, even after connecting my github account with AppVeyor. I ended up closing and reopening, but this wastes resources on Travis and now MSTS. On the rerun, it failed the first time and then passed on the rerun

2 2

Re: [python-committers] Visual Studio Team Services checks on pullrequests
by Steve Dower 17 May '18

17 May '18

Okay, now that it's morning and I have coffee, here's a full update on what I've been doing (those at the language summit have heard some of this already). Visual Studio Team Services is Microsoft's integrated code/build/release infrastructure service. The official marketing page is https://www.visualstudio.com/team-services/ but you can think of it as github code+github issues+Travis but engineered for huge teams (i.e. Microsoft keeps all of Windows in git, all the millions of issues they have, and all the builds they do, are in VSTS and it scales to thousands of developers just fine). I've been working with the team to improve their Python support and generally raise awareness of the new service, and one of the things they agreed to is to provide a free set of build machines for CPython. These allow us to run up to 20 simultaneous Windows, macOS and Linux builds with no other limits. My main project at the PyCon US sprints has been setting these builds up. As of about 16 hours ago the PR builds are now hooked up to github (for an example, see https://github.com/python/cpython/pull/6933). They are not required to merge, so don't feel the need to block PRs if everything else passes, but we'd like to fix up the issues they are hitting. As far as I can tell, most of the problems are transient test failures that ought to be fixed anyway. Brief interruption for some links: * https://python.visualstudio.com/cpython/_build/index?_a=queued (queued and recently completed builds) * https://github.com/python/cpython/tree/master/.vsts (build definitions) * https://github.com/python/cpython/pull/6933 (sample PR with build status) Authentication for python.visualstudio.com is currently manually managed, but everything relevant under https://python.visualstudio.com/cpython is visible without authentication (this is a new VSTS feature that we got enabled early). Right now I don't want to add lots of people manually, and we'll be looking at how to make this simpler in the future. There isn't much you can do while logged in anyway :) There are some missing features. I'm still in contact with the team and I'll be passing along requests, so feel free to let me know if you need anything. Currently I'm aware of: * no way to requeue a PR build (whether logged in or not) * no link from a build to the github PR page * templated build steps aren't enabled yet (see linux-deps.yml if you're interested) We don't yet have a specific timeline for making VSTS builds required and reducing Travis/AppVeyor usage. I also haven't set up VSTS for Python 2.7, and honestly I'm fine with keeping the existing systems there. As a slight aside, we're also working with some other projects to provide similar setups (specifically Twisted and some PyPA-associated projects), so if you think you'd benefit from this on one of your other projects let me know and we can see what's available. Also, if you start evaluating/using VSTS for other projects because of this, *please* let me know. New users is what the VSTS team is trying to achieve, so every time I can send back positive reports it helps convince them to keep donating build time. Feel free to email me with any questions or feedback, either on or off-list. Cheers, Steve

4 5

Re: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!
by Serhiy Storchaka 17 May '18

17 May '18

17.05.18 21:43, Elvis Pranskevichus пише: > I'm working on the What's New document. Will start putting PRs in the > next few days. Great!

1 0

Re: [python-committers] Visual Studio Team Services checks on pullrequests
by Benjamin Peterson 17 May '18

17 May '18

On Wed, May 16, 2018, at 15:27, Steve Dower wrote: > Thanks Microsoft for the 20 concurrent builds on Windows, macOS and Linux :) That is quite generous! Will it be ongoing?

2 1

Visual Studio Team Services checks on pull requests
by Steve Dower 16 May '18

16 May '18

Hi all Just a quick note right now - don't have time for all the details. I'm experimenting with using Visual Studio Team Services to do builds of CPython. Right now, you'll probably see failed builds on all PRs while I get security options figured out. These *will not* block your PR, so feel free to ignore them. Apologies for the noise in the meantime. Cheers, STeve

1 1