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).
Hello,
Just a heads up that the following PR:
https://github.com/python/cpython/pull/552/files
has generated a lot of spurious PR additions on bugs.python.org,
probably because that PR references a lot of issues
(example: https://bugs.python.org/issue23839).
Perhaps it would be nice to have an upper limit on the number of
notified issues when the PR mentions several of them?
(I'm sure someone more active than me, such as Victor or Serhiy, got *a
lot* of notifications from that PR :-))
Regards
Antoine.
Hello,
I am curious about the decision to have Travis-CI tests with both clang
and gcc. clang is a compiler which strives to be very compatible with
gcc. I would understand testing under OS X with clang in addition to
Linux with gcc, but I'm skeptical we gain much from testing both gcc and
clang under Linux. Also, it lengthens CI times, as clang produces
slower code in debug mode than gcc does (because we use "-Og" on gcc).
Or perhaps we could switch the clang build to produce a non-debug
interpreter (and therefore a faster test suite)?
Regards
Antoine.
(reposting, cc'ing python-dev)
It’s that time again: time to start thinking about the Python Language Summit!
The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the
Oregon Convention Center in Portland, Oregon, USA. Your befezzled hosts Larry
and Barry will once again be at the helm.
The summit’s purpose is to disseminate information and spark conversation
among core Python developers. It’s our yearly opportunity to get together for
an in-person discussion, to review interesting developments of the previous
year and hash out where we’re going next. And we have lots to talk about!
Since our last summit, Python 3.6 was released, and the main CPython
development process has been moved to GitHub. Naturally Python 3.7
development continues apace.
Speaking of changes, we’re continuing to evolve the summit. Everyone seemed
to like the lightning talks, so we’ll keep those. Everyone seemed to hate us
keeping the schedule secret -sorry!- so we’ll make that available beforehand,
with the understanding that it’ll be fluid as the day progresses. Due to room
size limitations and the yearly increase in participation, we’re limiting
summit invitations to just core developers and invited speakers. As usual,
we’ll have whiteboards and a projector. But this year we’re adding roaming
microphones, so everybody in the room will be able to hear your question!
With the help of the ever awesome Ewa, this year we’ll have badge ribbons for
Language Summit participants, which we’ll hand out at the summit room in the
morning.
As with last year, we’re using Google Forms to collect signups. The form will
let you request an invitation to the summit and optionally propose a talk.
Signups are open now, and will remain open until Wednesday April 12th, 2017.
You can find the link to the signup form from the summit’s official web page,
here:
https://us.pycon.org/2017/events/language-summit/
But never forget: you don’t need to be registered for PyCon in order to attend
the summit!
One final note. We’re re-inviting Jake Edge from Linux Weekly News to attend
the summit and provide press coverage. Jake’s done a phenomenal job of
covering the previous two years’ summits, providing valuable information not
just for summit attendees, but also for the Python community at large. Jake’s
coverage goes a long way toward demystifying the summit, while remaining
respectful of confidential information that’s deemed “off the record” ahead of
time by participants.
We hope to see you at the summit!
[BL]arry
https://twitter.com/benbalter/status/845305265159376896
Basically all of us will get to see when someone is a first-time
contributor (it's not publicly visible, only to people who can merge PRs).
I suspect that will not only lead to some of us being extra hands-on and
forgiving of mistakes, but maybe even try to make a decision about the PR
faster so they are not left wondering the fate of the PR.
I can't believe it's been 4 weeks. It feels like it was ages/yesterday when
we moved. :)
First, I hope people are not regretting letting/having me make this
migration. I know there have been some things to work through (and others
still to come), but I hope this is all a net positive (either now or in the
near future).
Second, I wanted to get initial feedback on things we can easily tweak:
- Requiring Travis to pass (I *really* don't want to turn this off as we
already had a broken build when I temporarily turned it off at someone's
request when Travis was backed up from the AWS S3 outage; I also don't plan
to make AppVeyor required unless there's a way to make it be skipped for
doc-only changes)
- Cherry-picking working out? (We can go back to forward merging if
people really want to, but I think long-term cherry-picking will allow for
more automation)
- Along with that, are the labels for cherry-picking working out?
(Some devs seem to like using title labels like `[3.6]` to flag
cherry-picks so it's more obvious in emails so I don't know if the labels
are really that useful)
- Is the mention bot helpful? (Our config is at
https://github.com/python/cpython/blob/master/.mention-bot and the docs
are at https://github.com/facebook/mention-bot)
- Anything to tweak about the coverage bot and reports? (Our config is
at https://github.com/python/cpython/blob/master/.codecov.yml and docs
at https://docs.codecov.io/docs/codecov-yaml)
Third, I wanted to point out some of the more critical discussions going on
at https://github.com/python/core-workflow/issues. Specifically,
https://github.com/python/core-workflow/issues/6 is working towards a
solution for Misc/NEWS so if you care about the final solution you should
participate there. After Misc/NEWS is solved the next step becomes solving
the cherry-picking overhead with a more automated approach. We are also
discussing closed branches to make the list of branches more manageable at
https://github.com/python/core-workflow/issues/31.
Fourth, the lack of messages showing up on bugs.python.org after a commit
is being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613.
I'm sure Ezio and Maciej would appreciate any help people may be able to
volunteer to help in solving the problem.
Fifth, anything I missed? :)
On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.1, the
first maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22
to great interest and now, three months later, we are providing the
first set of bugfixes and documentation updates for it. Although it
should be transparent to users of Python, 3.6.1 is the first release
after some major changes to our development process so we ask users
who build Python from source to be on the lookout for any unexpected
differences.
Please see "What’s New In Python 3.6" for more information:
https://docs.python.org/3.6/whatsnew/3.6.html
You can find Python 3.6.1 here:
https://www.python.org/downloads/release/python-361/
and its change log here:
https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-1
The next maintenance release of Python 3.6 is expected to follow in
about 3 months by the end of 2017-06. More information about the 3.6
release schedule can be found here:
https://www.python.org/dev/peps/pep-0494/
--
Ned Deily
nad(a)python.org -- []
For now all Travis CI builds failed. This blocks merging new PRs,
backports and old PRs that need resolving Misc/NEWS conflicts.
For details see https://github.com/python/core-workflow/issues/54 .
Hi,
I imported my cherry picker script into https://github.com/
python/core-workflow/tree/master/cherry_picker/
Please try it out if you need to do backports for CPython. It still needs
some improvement with handling merge conflict, but if you don't anticipate
any conflict then it should make things easy for you. (things that do not
involve Misc/NEWS, for example)
After the migration, I used it to cherry-pick this PR:
https://github.com/python/cpython/pull/670 can confirm it works.
Thanks Nick Coghlan who has started using and contributing to it too :)
I believe he has a PR coming soon that adds a --dry-run option, which I
look forward to :)
Mariatta Wijaya
Hi folks,
I use "make patchcheck" a fair bit as a checklist for whether or not a
change needs any further adjustments before merging, but found it's
patch-based approach less then helpful with the new PR-centric workflow.
Accordingly, I just merged a few key updates to master and the 2.7/3.5/3.6
branches:
- it will automatically determine the current base branch, and check all
files changed relatively to that branch, rather than only checking
uncommitted changes
- it accepts any ".git" entry as indicating a checkout (nor just
directories), since "git worktree" defines ".git" as a configuration file
The automatic determination of the base branch is as follows:
- if an "upstream" remote is defined, it's used as the base branch remote,
otherwise "origin" is used
- if sys.version_info.releaselevel is "alpha", the base branch is
"<remote>/master"
- otherwise it is "<remote>/X.Y" (also based on sys.version_info)
Note that this works fine for "make patchcheck" (since it uses the just
built Python to run Tools/scripts/patchcheck.py), but anyone running the
tool directly rather than through the makefile may have to adjust how they
do things.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
