[Distutils] Implementing large changes in small increments

[Ian Cordasco]

On Fri, Mar 6, 2015 at 4:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 6 Mar 2015 22:10, "Ben Finney" <ben+python at benfinney.id.au> wrote:
>>
>> Nick Coghlan <ncoghlan at gmail.com> writes:
>>
>> > CPython uses the Reitveld instance integrated with bugs.python.org,
>> > and has the same problem as pip: incremental changes are a pain to
>> > publish, review, and merge, so we review and accept monolithic patches
>> > instead (cf the problem statement in
>> > https://www.python.org/dev/peps/pep-0462/)
>>
>> Fair enough. I don't know of a good code review tool for Mercurial.
>
> 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.
>
> 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).
>
>> > While the main UI is very busy, I've actually quite liked my own
>> > experience with Gerrit for http://gerrit.beaker-project.org/
>>
>> My understanding is that Gerrit makes it tedious to review a sequence of
>> revisions, in proportion to the number of revisions in the sequence.
>
> When the goal is to break a change up into small, independently reviewable
> changes that's generally a feature rather than a defect :)
>
>> If
>> I understand correctly, such a sequence must have separate reviews for
>> every revision, and an aggregate of all the changes is not available to
>> the reviewer.
>
> 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.
>
>> I'm impressed by GitLab's code review tool UI; see an example at
>> <URL:https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/344/diffs>.
>> The merge request page has tabs for the discussion, the commit log, and
>> the overall diff – and you choose from inline diff or side-by-side diff.
>>
>> GitLab is free software, including all its tools; anyone can set up a
>> GitLab instance and the project data can move from one instance to
>> another without loss. For the purposes of the past thread where some
>> proposed migrating to the proprietary lock-in site GitHub, those
>> objections don't exist with GitLab: a project can migrate to a different
>> host and keep all the valuable data it accumulated.
>>
>> A move to GitLab would be unobjectionable, in my view. That it has good
>> code review features would help the issues in this thread too.
>
> 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.
>
> 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 :)
>
>> If anyone knows of equivalent hosting for Mercurial with equivalent code
>> review tools under free-software terms with no lock-in, that would be
>> even better I think.
>
> That's what I'd like forge.python.org 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).
>
> Hence my suggestion that a "forge.pypa.io" 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
> https://www.python.org/dev/peps/pep-0481/ 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).
>
> Cheers,
> Nick.
>
>>
>> --
>>  \     “Don't be misled by the enormous flow of money into bad defacto |
>>   `\    standards for unsophisticated buyers using poor adaptations of |
>> _o__)                                     incomplete ideas.” —Alan Kay |
>> Ben Finney
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>

I'm fairly concerned that what has turned into a "how can we increase
the feedback received for people submitting pull requests" has turned
into a bike shed moment for using F/LOSS tooling instead of GitHub
when the cores who actually work on the project have already expressed
a disinterest in moving and a satisfaction with GitHub.

GitLab's UI would do nothing to improve review management.

Phabricator, while nice, again adds yet another layer to the piece for
new contributors to involve themselves in. GitHub is one monolith and
closed source (and a company with culture problems) but that doesn't
change the fact that it's the core developers choice what software to
use and they've (for the time being) chosen GitHub. Can we please stop
this discussion already? It's no longer beneficial or relevant.