On Fri, Mar 13, 2015 at 2:26 PM, Nick Coghlan <[email protected]> wrote: > On 13 March 2015 at 22:08, Brett Cannon <[email protected]> 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). > 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). 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. 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. > 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. Best Regards, Ezio Melotti > 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
