Hello fellow committers!
I'm organizing another core sprint this year to make Python 3.7 the best release possible.
WHY:
1. Community. The sprints at the end of PyCon are great but they mostly get the same people in the room year after year. Many of the most active contributors never attend conferences. My goal with this sprint is to bring together many core devs who rarely if ever meet!
2. Focus. When we have sprints at the end of a conference, many of us are pretty tired and less productive than we could have been without the late dinners, endless hallway sessions, and so on. Some of the sprinters are preoccupied with tutoring newcomers. This sprint won't be after a major conference, and it's only for seasoned CPython core devs--so get to work!
3. Communication. There are tremendous benefits to getting everyone together in one big room. Conversations that drag on on python-dev can be solved quickly in person. Even contentious debates become faster, easier, and more civil. And meeting face-to-face helps us all feel more connected to our community.
WHY THE BAY AREA: We have a large population of core contributors here. Also, I can arrange for Facebook to provide us a "war room" for the whole week, with full access to the campus during the sprints. That includes free food for breakfast, lunch, dinner, and snacks, compatible with almost any dietary restrictions.
WHY EARLY SEPTEMBER: It's almost impossible to find a time that doesn't overlap with a PyCon. This week worked well last year so we're redoing it that way. Monday September 4 is Labor Day in the US, which may make it easier for employees of US companies to attend, as they'd only be taking off four days instead of five.
HOW LONG: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can check into your hotel the day before the sprint (Sunday, Sep 3) and check out the day after (Saturday, Sep 9).
HOW BIG: No fewer than 10, no more than 20. More than 20 people would be great but it'd be hard for me to organize a sprint that big.
WHO PAYS: The venue, hotels, and food are provided by Facebook. I'm working on getting flight reimbursements. Last year they were provided by the Python Software Foundation. Anybody is free to waive their reimbursement.
PLEASE REPLY: If you're interested in attending and have the commit bit on GitHub's python/cpython, fill out this Google Form:
https://goo.gl/forms/MzrNtRe0NAmzvGwF2 <https://goo.gl/forms/MzrNtRe0NAmzvGwF2>
DISCLAIMER: I'd like to be able to host everybody. However, if I receive more than 20 applications, this is not going to be possible. In this case, the following will happen:
1. I will look at your current level of involvement in CPython development. This includes metrics like commits / PRs, activity on the bug tracker and python-dev, special role (release manager, infrastructure dev, etc.).
2. I will look at your sprint plan and ability to participate in the entire sprint (per answers to the questions above).
3. I will gather all this data and leave the final decision to our Benevolent Dictator (who is also attending the sprint). This is one of those occasions where having a dictator is useful.
DON'T WAIT: September is closer than you think! Please let me know as soon as possible so we can start setting up the event. I'm going to close the sign-up form on June 23rd.
Organizational-ly yours,
Ł
Vice-Minister of Silly Sprints
Hi,
The CPython workflow was enhanced to get pre-commit CI checks. That's
a huge win, thank you for that... But, sometimes, a change can still
break many buildbots, bugs which weren't catched by pre-commit checks
(Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more
different architectures and platforms.
I spend a significant amount of time to maintain the sanity of our
buildbots. Sometimes, it can take me up to 3 days on a week (of 5
working days). It's annoying to see new regressions while I'm trying
hard to fix old ones :-(
So I would like to set a new rule: if I'm unable to fix buildbots
failures caused by a recent change quickly (say, in less than 2
hours), I propose to revert the change.
It doesn't mean that the commit is bad and must not be merged ever.
No. It would just mean that we need time to work on fixing the issue,
and it shouldn't impact other pending changes, to keep a sane master
branch.
What do you think? Would you be ok with such rule?
A recent example is Nick Coghlan's implementation of the PEP 538:
basically, it broke all buildbots... except of Linux and Windows :-)
And it will take a few more days to fix all failures. Well, we are
working on fixing these issues, so I don't want to revert this change.
It's just an example of a single change which broke many buildbots.
The PEP 538 depends a lot on the platform, so I'm not surprised to see
different failures per platforms ;-)
By "buildbot failure", I mean a red buildbot failing because of
compilation error or failed test suite. But I would prefer to ignore
failures of the Refleak buildbots since these ones are not stable
(even if there are less and less ref leaks in master, and these
buildbots already catched recent regressions!).
If the rule is approved, I plan to announce it on python-dev to be transparent.
Victor
I just pushed a change to master, 3.6, and 3.5 where
Tools/scripts/patchcheck.py now has a --travis option which will run the
whitespace fixers from `make patchcheck` but trigger a Travis build failure
if any changes were necessary. This only runs on Linux so it is a PR
blocker, but also so it isn't done more than once per PR.
This was not backported to 2.7 because I honestly didn't want to do the
work to fix the merge conflicts.
Hi,
I was waiting for the result of Travis CI: 3 jobs already completed,
but the macOS job was still running. The macOS job is marked as
"allowed failure". I cancelled the job, but then the Travis CI was
marked as failed in the PR :-/ So I restarted the job.
Is it normal to have to wait for the slow macOS job to be able to merge a PR?
It's a recent change, no?
Victor
My apologies if this has been discussed/answered before, but is there a link from the github side to the bpo side? For
example, I'm looking at https://github.com/python/cpython/pull/2304 and it would be great if such a link existed to take
me directly to the bpo issue.
--
~Ethan~
One minor but ongoing problem we've had in CPython core development has
been the mess of updating Misc/NEWS. Day-to-day developers may have a
conflict if they lose a push race, which means a little editing. You'll
have a similar, if slightly worse, problem when cherry-picking a fix
between versions. Worst of all used to be the manual merges necessary
after cutting a release--this was the bane of a CPython release
manager's existence. (Though the new git-based workflow may have
obviated the worst of this.)
The real problem is that we have one central file that everybody
continually edits in a haphazard way. We aren't actually editing the
same information, we aren't actually changing the same lines. But our
revision control systems and diff algorithms don't understand the
structure of Misc/NEWS and so they get confused. And for what? It's not
like there's a tremendous benefit to having this central file everyone's
fighting over.
We've been talking about addressing this for years. Fixing this was one
of the goals of the new workflow. And finally, as of right now, the
future is here. Ladies and gentlemen, I present: blurb.
https://github.com/python/core-workflow/tree/master/blurb
blurb is an interactive command-line tool that helps you write Misc/NEWS
entries. You simply run blurb from anywhere inside a CPython repo.
blurb runs an editor for you with a template open. You fill in these
three pieces of information:
* the bugs.python.org or "bpo" issue number,
* what "section" of Misc/NEWS this entry should go in (by uncommenting
the correct line), and
* the text of the Misc/NEWS entry, in ReST format.
You save and exit and you're done. blurb even stages the Misc/NEWS
entry in git for you!
Behind the scenes, blurb writes your information here:
Misc/NEWS.d/next/<section-name>/<filename>
The "<section-name>" is the name of the section in Misc/NEWS where your
entry should go. <filename> contains the current date and time, the bpo
number, and a nonce to prevent collisions.
These "next" files get merged together into a single aggregate .rst file
by the release manager when cutting a release (using "blurb release").
One nice feature of this approach: when you cherry-pick a change, its
Misc/NEWS entry in "next" gets cherry-picked along with it.
One important change: Misc/NEWS will no longer be checked in. It'll
still be present in CPython tarballs; it will be generated by the
release manager as part of cutting a release. But as a repository of
information, it's been superseded by the various blurb data files. And
by regenerating it from data files, we ensure that we'll never ever have
a Misc/NEWS conflict ever again!
The plan is to leave Misc/NEWS in the CPython repo for maybe another
week, to let the current crop of PRs get merged. But new work should
switch to using blurb immediately.
You can install blurb from pip:
% pip3.6 install blurb
In fact--please do!
//arry/
Hello,
This is a bit of a futile question, but I realize I'm nowhere to be seen
in https://github.com/python/cpython/graphs/contributors
Is there some map file somewhere that I must update to match my commit
e-mail to my GitHub account?
Regards
Antoine.
On 24 June 2017 at 14:01, Craig Rodrigues <rodrigc(a)freebsd.org> wrote:
> On Fri, Jun 23, 2017 at 8:24 PM, Larry Hastings <larry(a)hastings.org> wrote:
>>
>>
>>
>> We've been talking about addressing this for years. Fixing this was one
>> of the goals of the new workflow. And finally, as of right now, the future
>> is here. Ladies and gentlemen, I present: blurb.
>>
>> https://github.com/python/core-workflow/tree/master/blurb
>
>
> Yes, when you have a single NEWS file that needs to get updated,
> the process begins to fall apart when you have a pull request type of
> workflow
> which results in many merge conflicts to the single NEWS file.
>
> Twisted and Buildbot use towncrier ( https://github.com/hawkowl/towncrier )
> which tries
> to solve the same problem as blurb.
Aye, towncrier and OpenStack's reno were the two main alternatives we
looked at in addition to Larry's offer of creating a tool specifically
for CPython: https://github.com/python/core-workflow/issues/6
We ultimately settled on blurb mainly because we wanted to be able to
customise various details differently from the way towncrier works,
and we figure they're close enough in spirit that folks familiar with
one won't have any problems adapting to the other.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
[Was: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California]
On Mon, Jun 12, 2017 at 4:04 PM, Lukasz Langa <lukasz(a)langa.pl> wrote:
> Hello fellow committers!
> I'm organizing another core sprint this year to make Python 3.7 the best
> release possible.
>
> *WHY*:
> 1. *Community*. The sprints at the end of PyCon are great but they
> mostly get the same people in the room year after year. Many of the most
> active contributors never attend conferences. My goal with this sprint is
> to bring together many core devs who rarely if ever meet!
> 2. *Focus*. When we have sprints at the end of a conference, many of us
> are pretty tired and less productive than we could have been without the
> late dinners, endless hallway sessions, and so on. Some of the sprinters
> are preoccupied with tutoring newcomers. This sprint won't be after a
> major conference, and it's only for seasoned CPython core devs--so get to
> work!
> 3. *Communication*. There are tremendous benefits to getting everyone
> together in one big room. Conversations that drag on on python-dev can be
> solved quickly in person. Even contentious debates become faster, easier,
> and more civil. And meeting face-to-face helps us all feel more connected
> to our community.
>
> *WHY THE BAY AREA*: We have a large population of core contributors
> here. Also, I can arrange for Facebook to provide us a "war room" for the
> whole week, with full access to the campus during the sprints. That
> includes free food for breakfast, lunch, dinner, and snacks, compatible
> with almost any dietary restrictions.
>
> *WHY EARLY SEPTEMBER*: It's almost impossible to find a time that doesn't
> overlap with a PyCon. This week worked well last year so we're redoing it
> that way. Monday September 4 is Labor Day in the US, which may make it
> easier for employees of US companies to attend, as they'd only be taking
> off four days instead of five.
>
> *HOW LONG*: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can
> check into your hotel the day before the sprint (Sunday, Sep 3) and check
> out the day after (Saturday, Sep 9).
>
> *HOW BIG*: No fewer than 10, no more than 20. More than 20 people would
> be great but it'd be hard for me to organize a sprint that big.
>
> *WHO PAYS*: The venue, hotels, and food are provided by Facebook. I'm
> working on getting flight reimbursements. Last year they were provided by
> the Python Software Foundation. Anybody is free to waive their
> reimbursement.
>
> *PLEASE REPLY*: If you're interested in attending and have the commit bit
> on GitHub's python/cpython, fill out this Google Form:
> https://goo.gl/forms/MzrNtRe0NAmzvGwF2
>
> *DISCLAIMER*: I'd like to be able to host everybody. However, if I
> receive more than 20 applications, this is not going to be possible. In
> this case, the following will happen:
>
> 1. I will look at your current level of involvement in CPython
> development. This includes metrics like commits / PRs, activity on the bug
> tracker and python-dev, special role (release manager, infrastructure dev,
> etc.).
> 2. I will look at your sprint plan and ability to participate in the
> entire sprint (per answers to the questions above).
> 3. I will gather all this data and leave the final decision to our
> Benevolent Dictator (who is also attending the sprint). This is one of
> those occasions where having a dictator is useful.
>
> *DON'T WAIT*: September is closer than you think! Please let me know as
> soon as possible so we can start setting up the event. I'm going to close
> the sign-up form on June 23rd.
>
> Organizational-ly yours,
> Ł
> Vice-Minister of Silly Sprints
>
> _______________________________________________
> python-committers mailing list
> python-committers(a)python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
--
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
It's time to start planning the next 3.5 release, 3.5.4. Note that this
will be the last 3.5 "bugfix" release; after 3.5.4, the 3.5 branch will
only be open for security fixes. 3.5.4 will also be the last release of
3.5 with binary installers.
I propose to tag and release 3.5.4 on these dates:
3.5.4rc1
tag Sat July 22 2017
release Sun July 23 2017
3.5.4 final
tag Sun Aug 6 2017
release Mon Aug 7 2017
Thus rc1 would be tagged in just over four weeks.
As for 3.4--
Lately I've been releasing new versions of 3.5 and 3.4 at the same
time. But I'm not sure it's worth the effort to release another 3.4
right now. There have only been two (2) checkins into the 3.4 branch
since 3.4.6 was released back in January:
f37b0cb230069481609b0bb06891b5dd26320504
bpo-25008: Deprecate smtpd and point to aiosmtpd
fa53dbdec818b0f2a0e22ca12a49d83ec948fc91
Issues #27850 and #27766: Remove 3DES from ssl
default cipher list and add ChaCha20 Poly1305.
The first was a documentation-only change which is already live on
docs.python.org. The second changes the _DEFAULT_CIPHERS and
_RESTRICTED_SERVER_CIPHERS constants in Lib/ssl.py. A reasonable
change, but minor. I'm not convinced it's worth spending the time of
many people in the community at large to update 3.4 just for this.
If you have any feedback / concerns about this schedule, or if you think
it's important that I release 3.4.7 with these minor changes, please
reply here. If I don't hear anything back in a day or two I'll go ahead
and make this the official schedule.
Your friendly neighborhood release manager,
//arry/
