Mailman 3 September 2015 - core-workflow

Testing out proposed new workflows
by Brett Cannon Oct. 28, 2015

Oct. 28, 2015

I have come to realize that asking for conversions of the devguide and peps repos to test with really won't give an accurate representation of how the workflows will apply to the cpython repository. Because of that I would like to see a test repo that starts from the cpython repo at some point in time that people can use to test things such as clean patch submissions, merge conflict submissions, etc. I'm not expecting Roundup integration for this nor that commits be integrated back into the repository of record. Basically I want to be able to grab a patch from Roundup and somehow apply it against a test repo to see how the workflow will work where I play both submitter and committer (e.g., a GitHub test repo where I can submit my own PRs against it that I know will fully succeed or have a merge conflict to test how things will look on both ends). Nick and Donald, do you think you can have such a test setup up and running by October 31 (Halloween, 88 days away)? If you honestly need more time I am willing to extend to November 15 (the cut-off in the retail industry to consider something in stores for Christmas, 113 days away), but I only want to do that if you honestly think the 15 extra days will make a difference. These dates will be enough for me and any other core developers who are interested to try out the test repos, give me feedback, and allow me to make a decision no later than January 1, 2016 so we can start the new year off towards getting our workflow back on track.

3 5

PEP 507 - Git & GitLab
by Barry Warsaw Oct. 1, 2015

Oct. 1, 2015

I'm not subscribed to this list directly, but I read it through Gmane. I've just published PEP 507 which proposes to move CPython development to Git and a hosted (donated or self TBD) GitLab instance. https://www.python.org/dev/peps/pep-0507/ All feedback is of course welcome, and if anybody else wants to hitch their ride to this pony, let me know and I'd be happy to add you as co-author of the PEP. Cheers, -Barry

3 2

Mercurial Sprints
by Pierre-Yves David Sept. 14, 2015

Sept. 14, 2015

Greeting, Python people, The mercurial community gather twice in the next 2 months, some of you might be interested to attend. It would be a good opportunity to share use case, paint point and get some bug squashed. This thursday, we'll have a minisprint in San Francisco: - https://mercurial.selenic.com/wiki/201509MiniSprintBayArea From October 23th to 25th we'll have a bigger, global sprint in London: - https://mercurial.selenic.com/wiki/3.6sprint See you there ;-) -- Pierre-Yves David

1 0

GSoC-powered bugs.python.org improvements
by Ezio Melotti Sept. 12, 2015

Sept. 12, 2015

Hi, As you might be aware, during the summer we had two GSoC students (mentored by Hieu Nguyen and me) working on bugs.python.org (b.p.o). Shiyao (mentored by me) worked on: * a Mercurial plugin for b.p.o -- this allows to see, download/apply, and generate/upload patches from/to b.p.o. Source @ https://bitbucket.org/introom/hg-cpydev -- based on previous work by Nick Coghlan and Mercurial core-dev Pierre-Yves David; * patch analysis for b.p.o -- this allows b.p.o to analyze and extract metadata from patches that can be used to e.g. find all the patches that affect a specific file, or determine if a patch contains tests or docs changes. Source @ https://bitbucket.org/introom/python-dev/src -- based on previous work by anatoly techtonik and me; * a Docker image for b.p.o -- this should make things easier for folks who want to hack on the tracker itself. Source @ https://bitbucket.org/introom/docker-b.p.o; Chau (mentored by Hieu) worked on adding a REST interface to Roundup. This lays the foundations for easily developing future tools and enhancements for b.p.o, including better stats, dashboards, Kallithea/Phabricator integration, console-based roundup client, etc. Source @ https://bitbucket.org/kinggreedy1991/roundup-bpo . A more detailed report about Shiyao work can be found at https://bpaste.net/show/6da721ff90db . A more detailed report about Chau work can be found at https://bpaste.net/show/7e2303d2aa7a . The Docker image and the Mercurial plugin can already be used (even though they should probably be reviewed in detail, added to hg.python.org, and documented in the devguide). The patch analysis and REST interface still need to be reviewed in detail and integrated. After testing the REST interface on b.p.o, the plan is to backport it to upstream Roundup. Since both me and Hieu are currently fairly busy with work, any help is more than welcomed. I would also like to take this opportunity to thank Shiyao and Chau for all the work they did, Hieu for volunteering as mentor, and Nick and R. David for sharing their ideas and suggestions about the projects. Best Regards, Ezio Melotti

3 3

the Misc/NEWS problem
by Brett Cannon Sept. 6, 2015

Sept. 6, 2015

If we ever want to have a nice workflow where we can automate as much as possible, we need to figure out a way deal with our most common merge conflict: Misc/NEWS. Thanks to shifts in the format between different minor versions the file is pretty much guaranteed to have a conflict when doing a merge up a version. So how do we solve this? I can remember 3 possible solutions that have been proposed previously: 1. A single file per entry 2. A single file per release version of Python 3. Automating it based on commit messages I personally prefer #3 as I hate repeating myself since I just copy and paste the first line(s) of my commits to Misc/NEWS as it is anyway (basically up to the first pair of newlines). We would need a way to signal that the commit message contains nothing useful for the to-be-generated NEWS file when it's simply a fix for a previous commit (probably some marker that is somewhat inconspicuous like a dash on its own line or something). In terms of the section of the NEWS file that a commit belongs, that can once again be a marker or honestly something we drop or infer based on what files were edited in the commit.

10 25