In the (long) discussion of https://github.com/python/core-workflow/issues/6,
Wes Turner began to do his usual posting of lists. People pointed out he
was stepping out of line by being somewhat off-topic and seemingly
lecturing folks. He posted some of his lists again and then I warned him
that if he did it again I would block him for a CoC violation since he did
not want to respect anyone's time by taking the time to edit what amount to
dumping his personal notes on GitHub. (This is a long-standing issue, BTW,
with Wes where he has been warned in other settings like distutils-sig
about his posting behaviour.)
Unfortunately he did it again for
https://github.com/python/core-workflow/issues/66. Since GitHub only has
organization-level blocks I have blocked him at that level (I've also
already received some +1s from core devs while writing this email for my
move, so I know others who have interacted with him also support this
decision).
At the moment Travis is not running the test build (it's actually not even
listing it as a build). You can look at master, 3.6, or 3.5 to see that
only the docs and coverage builds are being run:
https://travis-ci.org/python/cpython/branches . I don't know why this is as
it was fine yesterday and then stopped working today. The last change was
from Antoine but its own Travis run ran fine so I don't think that caused
the problem: https://github.com/python/cpython/commits/master/.travis.yml .
If anyone can figure out if this is somehow our fault that would be great
(I can't see how it is).
But the key thing is to be aware that Travis being green just means the
docs built fine. So until this is resolved, try to remember to check if the
coverage test run passes if you want Travis to check your non-doc changes.
Hi all,
It looks like appveyor tests are currently failing on all builds (something
about UNC paths + imports). Was appveyor enabled recently, or did the test
regress?
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
After reading a tweet from Nick (
https://twitter.com/ncoghlan_dev/status/868343982698266624) I realized it
probably would have been good to label PRs from sprinters at PyCon US so
they could get priority while the contributor was in the room or at least
try to address them quickly after the sprint. So I added a "sprint" label
that can be added to any PRs created during a sprint.
https://github.com/python/cpython/labels now have prefixes for all labels
to make it easier to find the relevant labels for some kind of
classification. For instance, all the labels for the type of PR -- e.g.
bugfix, enhancement, etc. -- now all have a "type-" prefix so you know what
your options are (adding more labels is also always an option). This also
makes it easier to tell which PRs are lacking possible labels for each
classification (e.g. which PRs don't have a "type" label yet).
While at the PyCon US sprints the idea came up of offering Carol Willing
developer privileges. Everyone at the table -- about 6 of us -- liked the
idea and Carol also said she would happy to become a core dev, so I'm
officially putting her forward for consideration.
For those of you who don't know Carol, she basically knows our developer
workflow better than most of us. :) ; she's very active on the devguide and
core-mentorship. Carol has also attended the PyCon US language summit two
years in a row as a representative for the Jupyter project. She is actually
so good with new people that she managed to get my wife to make her first
open source contribution (something I never managed to do).
As usual, if you support/object to this idea, please say so. :)
Hi,
I wanted to wait a little bit before giving back my feedback on the
new workflow. I just attend Brett Canon's talk at the Language Summit.
So here are my misc notes on the new workflow.
* Is there anyone already working on the workflow who would like to
get a grant (money!) from the PSF?
* If I want to share a change to review but it must not be merged,
would it be possible to prevent merge by mistake? Maybe add [WIP] to
the title and modify our bot to mark the "build" as failed? For
example, I wrote a patch which depends on a different patch but I
didn't want to create a patch serie since it didn't make sense.
* AppVeyor is now quite stable. I fixed a few unstable tests. I
suggest to mark this CI as mandatory. The CI is as fast or even faster
than Travis CI! But it seems like it accepts less jobs in parallel :-/
It might be an issue if we get a huge number of PR in a short period
(ex: during an event like Pycon US).
* Currently, cherry-picker works a single step. It would be nice to
have at least 2 steps: first cherry-pick locally, then allow to review
the patch locally and run some specific tests, and then send the PR.
By the way, instead of only using the sha1 to build the branch name,
it would be nice to add also the bpo number.
* I suggest to track backports at bpo since an issue tracks all PR and
it seems like most core developers want to put most informations in
the issue rather than GitHub.
* Find a way to keep the Code coverage job, but don't mark the PR as
failed if the coverage is considered as "failed"? It's strange to see
a long list of PR with the red sign (failed) whereas Travis and
AppVeyor passed.
I have a lot of other minor remarks, but I prefer to stop here ;-)
Victor
People didn't always remember to add the labels and they were redundant
with people specifying the branch in the title along with the PR that the
cherry-pick originated from (e.g. "[3.6] Something changed (GH-12345)").
