[core-workflow] bugs.python.org-related GSoC project

[Nick Coghlan]

On 14 March 2015 at 04:39, Carol Willing <willingc at willingconsulting.com> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia