On 14 March 2015 at 04:39, Carol Willing <[email protected]> wrote: > * Push button patch generation from a GitHub repo > > This looks like a well bounded project for a student.
It occurs to me also that this could potentially be done in a hosting service independent way by using Marcin Kuzminski's vcs module to actually generate the patch directly from the remote repo: https://pypi.python.org/pypi/vcs Added bonus: that library is the basis of the Git & Mercurial support in Rhodecode and Kallithea as well, so a patch generation utility based on it would potentially be useful for those projects as well. To avoid have to enter the full URL every time, we could potentially have something where a user could specify a CPython clone URL in their user preferences, and then prepopulate the VCS URL for patch generation based on that and a branch name based on the issue number like "issue12345". > * Some tool that will update a checkout (or somehow make sure a clone is > clean for patching), grab a patch from an issue, apply it, run the test > suite, and then ask if the committer wants to commit the patch and submit it > (assuming everything else worked out in favour of committing the patch); > > This looks like a good student project with valuable experience for the > user. Pierre-Yves David (one of the Mercurial devs) has been working on a Mercurial extension for that at https://bitbucket.org/ncoghlan/cpydev/src/default/cpyhg.py?at=default He's hoping to spend more time on it soon so folks will have something to try out at the PyCon sprints, so I wouldn't bet on this idea still being around as a candidate project by the time GSoC rolls around. > essentially script what the fancy workflows being proposed using > Phabricator/Kallithea do with the assumption the code was already reviewed > in the issue tracker and deemed worthy of being committed Yeah, our general inspiration for the idea is actually OpenStack's git/Gerrit review plugin: https://github.com/openstack-infra/git-review >> Understanding in which direction we want to go will allow me to put >> together a project that, once completed, will have long-term benefits >> for our workflow. >> Perhaps I should post this to python-dev too and get feedback from a >> wider audience. > > If you want, but I would assume everyone who cares is here at least for an > initial discussion. I've found one neat trick for this kind of scenario is to devise standalone projects that are likely to be useful regardless of what happens in the broader context. REST-API-in-upstream-Roundup qualifies, and I think a vcs based utility library for easily generating patches from remote repos would likely also be useful, independently of its integration into our Roundup instance. >> > Sure, we're likely to stop using Rietveld in favour of the winner of >> > the forge.python.org analysis at some point in the future, but that >> > point is likely to be quite some time away where CPython is concerned. >> > >> >> Having a student investigating how Kallithea and Phabricator will >> interact with Roundup and start developing a proof-of-concept >> integration and/or tools that we already know will be needed might >> also be an idea. >> > > Yes, especially if I can make a decision fast enough to know which one to > focus on. For the record, the reason it was fairly straightforward for me to wrangle some work time to spend on containerisation and related development workflow improvements for open source services like Kallithea was publicly announced last Friday: http://connect.redhat.com/zones/containers :) The relevant upstream bits are also there already (https://github.com/projectatomic/adb-atomic-developer-bundle) but there's still some work to do to on that front to integrate community Linux platforms in addition to RHEL. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
