<p dir="ltr"><br>
On 6 Mar 2015 22:10, "Ben Finney" <<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>> wrote:<br>
><br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> writes:<br>
><br>
> > CPython uses the Reitveld instance integrated with <a href="http://bugs.python.org">bugs.python.org</a>,<br>
> > and has the same problem as pip: incremental changes are a pain to<br>
> > publish, review, and merge, so we review and accept monolithic patches<br>
> > instead (cf the problem statement in<br>
> > <a href="https://www.python.org/dev/peps/pep-0462/">https://www.python.org/dev/peps/pep-0462/</a>)<br>
><br>
> Fair enough. I don't know of a good code review tool for Mercurial.</p>
<p dir="ltr">I'd like to ensure Kallithea fits that bill, but the actual work on that seems to mostly be driven by the folks at Unity3D at the moment.</p>
<p dir="ltr">In the meantime, Phabricator is a decent choice if you just want to use an existing GitHub independent tool that works with either git or Mercurial. pip adopting that workflow would also be a good proof of concept for Donald's proposal to also adopt that workflow for CPython (or at least its support repos).</p>
<p dir="ltr">> > While the main UI is very busy, I've actually quite liked my own<br>
> > experience with Gerrit for <a href="http://gerrit.beaker-project.org/">http://gerrit.beaker-project.org/</a><br>
><br>
> My understanding is that Gerrit makes it tedious to review a sequence of<br>
> revisions, in proportion to the number of revisions in the sequence.</p>
<p dir="ltr">When the goal is to break a change up into small, independently reviewable changes that's generally a feature rather than a defect :)</p>
<p dir="ltr">> If<br>
> I understand correctly, such a sequence must have separate reviews for<br>
> every revision, and an aggregate of all the changes is not available to<br>
> the reviewer.</p>
<p dir="ltr">Correct, but my understanding is that when using it in tandem with GitHub, there's nothing stopping you from also submitting a PR if a reviewer wants an all-inclusive view.</p>
<p dir="ltr">> I'm impressed by GitLab's code review tool UI; see an example at<br>
> <URL:<a href="https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/344/diffs">https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/344/diffs</a>>.<br>
> The merge request page has tabs for the discussion, the commit log, and<br>
> the overall diff – and you choose from inline diff or side-by-side diff.<br>
><br>
> GitLab is free software, including all its tools; anyone can set up a<br>
> GitLab instance and the project data can move from one instance to<br>
> another without loss. For the purposes of the past thread where some<br>
> proposed migrating to the proprietary lock-in site GitHub, those<br>
> objections don't exist with GitLab: a project can migrate to a different<br>
> host and keep all the valuable data it accumulated.<br>
><br>
> A move to GitLab would be unobjectionable, in my view. That it has good<br>
> code review features would help the issues in this thread too.</p>
<p dir="ltr">It doesn't have the integration with other services and the low barriers to contribution that are the main reasons a lot of projects prefer GitHub.</p>
<p dir="ltr">Of course, when your problem is already "we're receiving more contributions than we can process effectively", deciding to require a slightly higher level of engagement in order to submit a change for consideration isn't necessarily a bad thing :)</p>
<p dir="ltr">> If anyone knows of equivalent hosting for Mercurial with equivalent code<br>
> review tools under free-software terms with no lock-in, that would be<br>
> even better I think.</p>
<p dir="ltr">That's what I'd like <a href="http://forge.python.org">forge.python.org</a> to eventually be for the core Python ecosystem, but we don't know yet whether that's going to be an entirely self-hosted Kallithea instance (my preference) or a Phabricator instance backed by GitHub (Donald's preference).</p>
<p dir="ltr">Hence my suggestion that a "<a href="http://forge.pypa.io">forge.pypa.io</a>" Phabricator instance might be an interesting thing to set up and start using for pip. Donald's already done the research on that in the context of <a href="https://www.python.org/dev/peps/pep-0481/">https://www.python.org/dev/peps/pep-0481/</a> and for pip that's a matter of "just add Phabricator" without having to migrate anything (except perhaps the issues if folks wanted to do that).</p>
<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">><br>
> --<br>
> \ “Don't be misled by the enormous flow of money into bad defacto |<br>
> `\ standards for unsophisticated buyers using poor adaptations of |<br>
> _o__) incomplete ideas.” —Alan Kay |<br>
> Ben Finney<br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>