[Distutils] Implementing large changes in small increments

[Donald Stufft]

> On Mar 6, 2015, at 5:43 PM, Ian Cordasco <graffatcolmingov at gmail.com> wrote:
> 
> 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.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

Tooling wise, Github PRs work well for us. I don’t (and I don’t believe that
any of the other core devs) have any major issues with them.

Github issues on the other hand, they function “OK” but it would be nice to
have something that we can allow anyone to modify the state of tickets to
help with triage. However even this isn’t a super pressing concern because
our ticket count is small enough that I don’t think there’s likely to be too
many to be handled by people commenting on issues and a core team coming in
to change things. However if someone has a proposal for a different issue
tracker (and plans for how to migrate to it), personally I’d be willing to
listen.

F/OSS tooling is nice, but I honestly care a whole lot less about that and a
lot more about whatever tooling is the most effective for us to get the job
done. This can include hosted services (and possibly even hosted services that
cost money). Written in Python is also nice, but again I honestly don’t care
about that nearly as much as I care about the tooling being effective.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150306/1df8bc80/attachment.sig>