Mailman 3 March 2016 - core-workflow

CLA bot is now live under the Python org on GitHub
by Brett Cannon March 28, 2016

March 28, 2016

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.

1 0

GitHub Workflow
by Oleg Broytman March 17, 2016

March 17, 2016

An interesting example of GitHub Workflow (used by Frameworks team at BBC News): http://www.integralist.co.uk/posts/github-workflow.html The basis of their workflow is this: -- Open a GitHub PR (Pull Request) by creating a new feature branch from master -- 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 feature commit Oleg. -- Oleg Broytman http://phdru.name/ phd(a)phdru.name Programmers don't die, they just GOSUB without RETURN.

4 7

Spelling out a suggested local workflow for sending PRs?
by Nick Coghlan March 8, 2016

March 8, 2016

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. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

7 13

Re: [core-workflow] the Misc/NEWS problem
by Doug Hellmann March 6, 2016

March 6, 2016

[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 > http://docs.openstack.org/releasenotes/nova/. > > If you're interested, I'm happy to answer questions here, now that > I'm subscribed to the list. > > Doug > >> >> 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 >>> revolt. >>> >>> 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> >>>> wrote: >>>> >>>>> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com> >>>>> wrote: >>>>>> OK, assuming David's in agreement then I think this approach wins with >>>>> the >>>>>> comma-separated field for commits that the hg hook for Roundup >>>>> auto-appends >>>>>> 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 >>>>> long >>>>>> will it take, and who is willing to do the work? With this in hand we >>>>> can >>>>>> propose it to python-committers for 3.6 since the NEWS file should be >>>>> easy >>>>>> 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 >>>>> work. >>>>> >>>>> 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. >>>> >>> >>

1 0

GitHub migration update
by Brett Cannon March 4, 2016

March 4, 2016

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/issue579 and 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 python org. 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).

1 0