https://github.com/python/the-knights-who-say-ni is the new home for the
code. I also created the https://github.com/the-knights-who-say-ni bot
account for when I finally turn the bot on.
Ezio moved this weekend but told me he plans to commit Maciej's code soon
(I told him he could make GitHub usernames public which simplifies
matters). Once that's done and I have verified the CLA bot ties into the
new API on b.p.o properly I will then ask Senthil for his final
recommendation on how to convert Mercurial repositories to Git and then
move the devinabox repository over. If that move works out then I will
switch the benchmarks repository over. Once both of those moves have been
verified to have worked then we will figure out what's necessary to update
the deployment steps for the peps and devguide repos and then move those
two over as well.
Then the "fun" begins in doing what's necessary to get cpython moved over
(e.g. getting feature parity with the current setup).
Overall, the goal still remains to move all repos sans cpython over to
GitHub by PyCon US and the cpython repo itself by the end of the year.
An interesting example of GitHub Workflow (used by Frameworks team at BBC
The basis of their workflow is this:
-- Open a GitHub PR (Pull Request) by creating a new feature branch
-- Make feature specific changes and request a code review
-- If given a "thumbs up", this means the PR author is allowed to
handle merging the PR
-- The merge process requires a set of sub steps (see below)
The steps (in summary) are:
-- Interactively rebase master onto the feature branch
-- Squash all feature commits into a single commit:
-- (this isn't exactly a squash)
-- the first line of the commit message should be the same as the
GitHub PR title
-- As part of the rebase ensure:
-- the author(s) is mentioned in the commit message
-- the PR is mentioned (and any associated issues as well)
-- Move back to the master branch and cherry-pick in the newly squashed
Oleg Broytman http://phdru.name/ phd(a)phdru.name
Programmers don't die, they just GOSUB without RETURN.
Something that came up at work recently was instructing people on how best
to configure local git clones for working with a "fork+PR" development
model, where you have your own server-side fork for the project that you
then use to submit pull requests. The trick is that there's an easy way to
do this and a hard way, and it isn't immediately obvious which is which :)
The easy way:
* clone the upstream repo read-only
* add your fork as an additional read/write remote:
* e.g. "git remote add pr <URL of fork>"
* work in a branch
* e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"
* publish via your fork, and then submit back to the main repo
* "git push pr"
* use the web UI to submit the PR
The hard way:
* clone your fork read/write
* still work in topic branches
* waste time keeping master in your fork up to date
* forget the previous step, and submit PRs against a stale version of master
I bring it up as when I first started using GitHub, the second way seemed
intuitively obvious to me, but it actually makes things harder than they
need to be.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
[I replied just to Brett, not the list.]
> On Mar 6, 2016, at 11:02 AM, Doug Hellmann <doug(a)doughellmann.com> wrote:
> Excerpts from bcannon's message of 2015-09-07 01:03:18 +0000:
>> I forgot to follow up here that there was nary a peep from
>> python-committers about the proposal of keeping NEWS entries in the issue
>> tracker, so we have a green light to implement this idea.
> Sorry for following up on this so late; I'm just catching up on the
> archives and project status.
> You might be interested in a tool called "reno" that we built for
> managing OpenStack release notes. Contributors place YAML files
> containing release notes in the source tree, and reno uses the git
> branch and tag history to determine which version those notes belong
> to and to build the set of notes to be displayed. There's a command
> line app to dump a simple RST file and Sphinx integration module
> to make it easy to integrate the published release notes along with
> other documentation. Because notes are part of the git history, it's
> easy to include them with patches copied into multiple branches for
> backporting fixes. Because notes are in files, instead of commit
> messages, it is possible to change the note after the fact. And because
> they're in files they go with the source.
> More info on reno (including design considerations) is available
> at http://docs.openstack.org/developer/reno/ and some published
> release notes for the Nova project are available at
> If you're interested, I'm happy to answer questions here, now that
> I'm subscribed to the list.
>> On Mon, Aug 10, 2015, 15:39 Brett Cannon <bcannon at gmail.com> wrote:
>>> I have told python-committers of our plan to make sure it won't lead to a
>>> On Sat, 8 Aug 2015 at 14:25 Brett Cannon <bcannon at gmail.com> wrote:
>>>> On Sat, Aug 8, 2015 at 1:18 PM R. David Murray <rdmurray at bitdance.com>
>>>>> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com>
>>>>>> OK, assuming David's in agreement then I think this approach wins with
>>>>>> comma-separated field for commits that the hg hook for Roundup
>>>>>> to and of course the field to enter the NEWS entry.
>>>>>> Now the next question is how easy/hard is it to implement this, how
>>>>>> will it take, and who is willing to do the work? With this in hand we
>>>>>> propose it to python-committers for 3.6 since the NEWS file should be
>>>>>> enough to back-fill to this approach while its still small.
>>>>> Yes I agree this is the best approach, assuming we can get it
>>>>> implemented. The advantage of #4, though, is that Ezio already did the
>>>>> I'm *willing* to do the roundup work, but I don't know as I have the
>>>>> required time, at least for the next month. Part of the trick is the
>>>>> need to get a test instance set up...there was work done at PyCon and
>>>>> after at making a tracker-in-a-box, so I'd need to find out where that
>>>>> was at and learn how to use it (or finish it, if needed). The code
>>>>> itself is probably a half-day job, probably including enhancing the hook
>>>>> to update the commits field. But together with getting a working test
>>>>> instance we're talking a couple days work at least.
>>>> Perk of getting the tracker-in-a-box working is it's a one-time cost that
>>>> will be beneficial long term.
>>>> I also don't think there is a rush since we still have to convince
>>>> python-committers that this is the right solution. I plan to propose it on
>>>> Monday to the list to make sure we have buy-in.
>>>>> Writing the NEWS generating script is a not exactly trivial job, but
>>>>> probably wants to wait until we have the REST API. So we'd have
>>>>> upgrading our Roundup to that when it lands on the list as well, with a
>>>>> 3.6 Beta 1 deadline on getting it all done.
>>>> Yeah, so we have a bit of time to worry about the generation script.
Just a quick update so people know what's going on.
First, thanks to Maciej Szulik for stepping up to help with bugs.python.org
changes! There are now patches to add a GitHub field for user accounts and
adding an endpoint for that data at
http://psf.upfronthosting.co.za/roundup/meta/issue581, respectively. Ezio
has told me he is busy ATM but is hoping to help get this stuff in the
middle of this month (although I'm sure patch reviews are always welcome).
Two, Senthil is still tracking the git -> hg migration tool choices at
https://github.com/orsenthil/cpython-hg-to-git . Since we're not migrating
yet there is no need to worry about getting an answer to this problem right
now. It sounds like hg-git might win out, in which case it might be worth
looking at what difference there may be between the ideal conversion and
what is already at https://github.com/python/cpython since if the output is
close enough it might be nicer to simply keep the current repo and not
break people's pre-existing checkouts.
Three, the CLA bot is coded sans the work required to integrate with the
future b.p.o endpoint: https://github.com/brettcannon/knights-who-say-ni.
At some point I will need a GitHub account for the bot and to get it hosted
on Heroku which is all stuff for infrastructure@ (which I'm handling). I
also need to move it over to the python org on GitHub instead of keeping it
under my personal account now that I have ownership privileges for the
Because people keep asking me privately, my hoped-for timeline is to get
the non-cpython repositories moved over by PyCon US 2016. As for the
cpython repo itself, my hope is to be ready to switch after Python 3.6.0 is
released (which is slated for December of this year). It may be possible to
move the cpython repo sooner, but there are enough parts to that migration
that it might be hard to get everything together faster than that, plus I
will need to talk with the 3.6 release manager to see if they are even
willing to migrate during the alpha or beta cycles of 3.6. But I definitely
want to try and see this completed no later than a year from when I
announced the final decision to move (which was Jan 1 of this year).