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).
[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
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.
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).
> 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.
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
> 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.
nad(a)python.org -- 
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
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
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
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
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.
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.