[python-committers] Workflow change reminder: The Blurb Has Landed
Yesterday I "blurbified" the 2.7, 3.6, and master branches in CPython. It's finally official: all* branches have now been "blurbified". This means that Misc/NEWS is no longer present in any of CPython's active branches. Instead, Misc/NEWS has been broken up into a zillion little files in the new Misc/NEWS.d directory tree. (Misc/NEWS can be reconstituted consistently from this directory tree.) This banishes forever the annoying problem of Misc/NEWS merge conflicts when you attempt to merge a pull request, when release managers create a release, etc. We announced "blurb" a month or two back, and you should already be creating your news entries in Misc/NEWS.d. But just in case, here's a quick refresher. The core-workflow team has created a tool called "blurb" that makes it easy to create a news entry for a commit. It's easy to install and use. You can install it with: python3 -m pip install blurb It requires Python 3.5 or newer. (Sorry, it can't get backported to 3.4 without fixing a bug in "re"... and 3.4 is closed for bugfixes.) To create a news entry, just run blurb from anywhere inside your CPython repo. On POSIX systems just make sure "blurb" is on your path, then simply run "blurb". On Windows the recommended method is "python3 -m blurb". When you run blurb, it'll guide you through creating a news entry. It'll pop open an editor window on a template. Just modify the template as needed, write your news entry at the bottom, and save and exit. blurb will write out your news entry as a uniquely-named file in Misc/NEWS.d--and even stage it for you in "git"! If for some reason you want to create news entries by hand, or if you just want more information, please see the Dev Guide: https://devguide.python.org/committing/#what-s-new-and-news-entries and the documentation for blurb on PyPI: https://pypi.org/project/blurb/ The migration to Misc/NEWS.d and blurb has a few other implications: 1. Existing pending PRs or patches with Misc/NEWS entries will need to be updated to generate the entry with blurb. (Again, there really shouldn't /be/ any by this point.) 2. If you want to read a branch's NEWS entries in a convenient format, simply use "blurb merge" to produce a temporary NEWS file. (But don't check it in!) See the blurb documentation. 3. As part of the release process, release managers now use blurb to merge all the individual NEWS.d/next files into a single NEWS.d file for that version. They'll also build a traditional monolithic Misc/NEWS included in the release's source tarball (but this won't get checked in). 4. If you're building 3.x docs from a cpython git repo, you'll now need to have blurb installed. You can use the "make venv" recipe in Doc/Makefile to create a python3 venv with blurb and sphinx. Happy blurbing! /arry * All except 3.3. Ned Deily has taken over as release manager of 3.3, and he thinks we shouldn't bother with blurbifying that branch--it'll reach end-of-life in mere weeks, and we're only going to make one more release of it, and it gets very little work done these days. p.s. Thanks to Ned Deily who originally wrote this email, which I hacked up and sent. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Travis CI: macOS is now blocking -- remove macOS from Travis CI?
Hi, I was bitten again by the issue on https://github.com/python/cpython/pull/3350 After restarting the Travis CI build twice (first by me, then by Zach), I was able to merge it. But it's painful to have to restart a whole build. And it wastes Travis CI resources :-( So I just proposed to drop the macOS job: https://bugs.python.org/issue31355 Please read the issue for the full rationale. Victor 2017-09-01 19:15 GMT+02:00 Victor Stinner : > Hi, > > Since today, it seems like the macOS task of a Travis CI job to > validate a pull request hangs the whole job. > > Don't try to cancel the macOS job, or the whole job will be marked as > failed! ... even if macOS is in the "Allowed Failure" section. I don't > know the best way to "repair" such job. I use "restart job" which > restarts all tasks, even the completed *and successful* Linux and doc > jobs. > > I have PRs waiting for longer than 2 hours for Travis CI. The macOS > job is seen as "queued". > > Yesterday, it was possible to merge a PR even if the macOS job was > still queued (no started). > > I never wait for macOS, since, as I wrote, it can take longer than 1 > hour. Moreover, macOS failures are not reported to the GitHub UI :-( > (Hum, in fact, I'm not sure about that.) > > Maybe we should remove the pre-commit macOS task from the Travis CI > config to focus on post-commit macOS buildbots? If we remove it, > should we remove it from 2.7, 3.6 and master branches? > > We have 3 macOS buildbots: > > * x86 Tiger 3.x > * x86-64 El Capitan 3.x > * x86-64 Sierra 3.x > > All three are currently green ;-) > > In the last 3 months, the macOS task of Travis CI caused multiple issues :-/ > > Victor ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Cherry picker bot deployed in CPython repo
Hi, The cherry picker bot has just been deployed to CPython repo, codenamed miss-islington. miss-islington made the very first backport PR for CPython and became a first time GitHub contributor: https://github.com/python/cpython/pull/3369 GitHub repo: https://github.com/python/miss-islington What is this? == As part of our workflow, quite often changes made on the master branch need to be backported to the earlier versions. (for example: from master to 3.6 and 2.7) Previously the backport has to be done manually by either a core developer or the original PR author. With the bot, the backport PR is created automatically after the PR has been merged. A core developer will need to review the backport PR. The issue was tracked in https://github.com/python/core-workflow/issues/8 How it works == 1. If a PR needs to be backported to one of the maintenance branches, a core developer should apply the "needs backport to X.Y" label. Do this **before** you merge the PR. 2. Merge the PR 3. miss-islington will leave a comment on the PR, saying it is working on backporting the PR. 4. If there's no merge conflict, the PR should be created momentarily. 5. Review the backport PR created by miss-islington and merge it when you're ready. Merge Conflicts / Problems? == In case of merge conflicts, or if a backport PR was not created within 2 minutes, it likely failed and you should do the backport manually. Manual backport can be done using cherry_picker: https://pypi.org/project/cherry-picker/ Older merged PRs not yet backported? == At the moment, those need to be backported manually. Don't want PR to be backported by a bot? My recommendation is to apply the "needs backport to X.Y" **after** the PR has been merged. The label is still useful to remind ourselves that this PR still needs backporting. Who is Miss Islington? = I found out from Wikipedia that Miss Islington is the name of the witch in Monty Python and The Holy Grail. miss-islington has not signed the CLA! = A core dev can ignore the warning and merge the PR anyway. Thanks! Mariatta Wijaya ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Cherry picker bot deployed in CPython repo
This is a great UX win for our development process. Thanks for making this happen! Alex On Tue, Sep 5, 2017 at 9:10 PM, Mariatta Wijaya wrote: > Hi, > > The cherry picker bot has just been deployed to CPython repo, codenamed > miss-islington. > > miss-islington made the very first backport PR for CPython and became a > first time GitHub contributor: https://github.com/python/cpython/pull/3369 > > > GitHub repo: https://github.com/python/miss-islington > > What is this? > == > > As part of our workflow, quite often changes made on the master branch > need to be backported to the earlier versions. (for example: from master to > 3.6 and 2.7) > > Previously the backport has to be done manually by either a core developer > or the original PR author. > > With the bot, the backport PR is created automatically after the PR has > been merged. A core developer will need to review the backport PR. > > The issue was tracked in https://github.com/python/core-workflow/issues/8 > > How it works > == > > 1. If a PR needs to be backported to one of the maintenance branches, a > core developer should apply the "needs backport to X.Y" label. Do this > **before** you merge the PR. > > 2. Merge the PR > > 3. miss-islington will leave a comment on the PR, saying it is working on > backporting the PR. > > 4. If there's no merge conflict, the PR should be created momentarily. > > 5. Review the backport PR created by miss-islington and merge it when > you're ready. > > Merge Conflicts / Problems? > == > > In case of merge conflicts, or if a backport PR was not created within 2 > minutes, it likely failed and you should do the backport manually. > > Manual backport can be done using cherry_picker: https://pypi. > org/project/cherry-picker/ > > Older merged PRs not yet backported? > == > > At the moment, those need to be backported manually. > > Don't want PR to be backported by a bot? > > > My recommendation is to apply the "needs backport to X.Y" **after** the PR > has been merged. The label is still useful to remind ourselves that this PR > still needs backporting. > > Who is Miss Islington? > = > > I found out from Wikipedia that Miss Islington is the name of the witch in > Monty Python and The Holy Grail. > > miss-islington has not signed the CLA! > = > > A core dev can ignore the warning and merge the PR anyway. > > Thanks! > > > Mariatta Wijaya > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -- "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 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Cherry picker bot deployed in CPython repo
Congrats! INADA Naoki On Wed, Sep 6, 2017 at 10:10 AM, Mariatta Wijaya wrote: > Hi, > > The cherry picker bot has just been deployed to CPython repo, codenamed > miss-islington. > > miss-islington made the very first backport PR for CPython and became a > first time GitHub contributor: https://github.com/python/cpython/pull/3369 > > GitHub repo: https://github.com/python/miss-islington > > What is this? > == > > As part of our workflow, quite often changes made on the master branch need > to be backported to the earlier versions. (for example: from master to 3.6 > and 2.7) > > Previously the backport has to be done manually by either a core developer > or the original PR author. > > With the bot, the backport PR is created automatically after the PR has been > merged. A core developer will need to review the backport PR. > > The issue was tracked in https://github.com/python/core-workflow/issues/8 > > How it works > == > > 1. If a PR needs to be backported to one of the maintenance branches, a core > developer should apply the "needs backport to X.Y" label. Do this **before** > you merge the PR. > > 2. Merge the PR > > 3. miss-islington will leave a comment on the PR, saying it is working on > backporting the PR. > > 4. If there's no merge conflict, the PR should be created momentarily. > > 5. Review the backport PR created by miss-islington and merge it when you're > ready. > > Merge Conflicts / Problems? > == > > In case of merge conflicts, or if a backport PR was not created within 2 > minutes, it likely failed and you should do the backport manually. > > Manual backport can be done using cherry_picker: > https://pypi.org/project/cherry-picker/ > > Older merged PRs not yet backported? > == > > At the moment, those need to be backported manually. > > Don't want PR to be backported by a bot? > > > My recommendation is to apply the "needs backport to X.Y" **after** the PR > has been merged. The label is still useful to remind ourselves that this PR > still needs backporting. > > Who is Miss Islington? > = > > I found out from Wikipedia that Miss Islington is the name of the witch in > Monty Python and The Holy Grail. > > miss-islington has not signed the CLA! > = > > A core dev can ignore the warning and merge the PR anyway. > > Thanks! > > > Mariatta Wijaya > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
