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

[Brett Cannon]

On Fri, Mar 13, 2015 at 12:15 PM Ezio Melotti <ezio.melotti at gmail.com>
wrote:

> On Fri, Mar 13, 2015 at 2:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 13 March 2015 at 22:08, Brett Cannon <bcannon at gmail.com> wrote:
> >> Another idea would be dropping Rietveld for some other code review tool.
> >> Guido has mentioned we should probably switch off since our copy of
> Rietveld
> >> no longer tracks upstream.
> >
> > That's probably not a good idea, given that both PEP 474 and PEP 481
> > suggest introducing new code review capable services as
> > forge.python.org (Kallithea and Phabricator respectively) so
> > regardless of how that competition turns out, there'll be a potential
> > replacement for Rietveld incoming.
> >
>
> If Rietveld is going to eventually be replaced, it might be better to
> focus the efforts on the bug tracker itself and avoid "large-scale"
> projects targeting Rietveld (e.g. updating it with upstream).
>

SGTM


>
> > Since both those PEPs suggest leaving the main CPython workflow alone
> > for the time being, and there's nothing actually *broken* with the
> > Rietveld integration, it could be worth pursuing some of the simpler
> > changers Ezio suggested, like pinging the tracker when a review is
> > filed, trying harder to find a base branch,
>
> These simpler features could still be implemented and they are
> probably worth the effort, even if Rietveld will be gone in a couple
> of years.
>
> > or (one we discussed on
> > IRC) better defining a workflow for generating patches directly from a
> > BitBucket Mercurial clone could still be worthwhile.
> >
>
> Determining the desired workflow(s) is one of the reasons why I am
> writing this email.
> With the current workflow someone posts a patch on the bug tracker and
> after a discussion/review a core-dev commits and pushes it.  Patch
> generation from a remote repo and patch review with Rietveld are also
> supported.
> If people desire more options, they could be added to the current
> workflow (e.g. a better integration with BitBucket, pull requests
> support, a Mercurial extension that allow contributors to post patches
> to b.p.o directly).
>

As Nick said, current plans are to try workflows with ancillary repos first
-- e.g. peps repo -- and then hopefully eventually graduate to helping with
CPython. So making it easier to pull patches from Bitbucket and GitHub
would be still be very useful. Same goes for the workflow cleanup that R.
David Murray proposed when this was first started.


> AFAIU the introduction of Kallithea/Phabricator and possibly other
> tools will likely change our workflow: we might start using pull
> requests instead of/in addition to patches, use other review tools
> instead of Rietveld, and even commit patches directly from the bug
> tracker or other tools.
>

Yes, but the workflow will bifurcate initially with CPython not changing
and everything else shifting. That means making things easier for CPython
today with its current workflow will still be beneficial.

My areas of focus would be:

* workflow simplification in the issue tracker like what R. David outlined
previously
* Push button patch generation from a GitHub repo
* 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);
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


>
> 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.


>
> > 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.

-Brett


> Best Regards,
> Ezio Melotti
>
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150313/9b69915f/attachment-0001.html>