> On Mar 6, 2015, at 5:43 PM, Ian Cordasco <[email protected]> wrote: > > On Fri, Mar 6, 2015 at 4:04 PM, Nick Coghlan <[email protected]> wrote: >> >> On 6 Mar 2015 22:10, "Ben Finney" <[email protected]> wrote: >>> >>> Nick Coghlan <[email protected]> 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 - [email protected] >>> https://mail.python.org/mailman/listinfo/distutils-sig >> >> >> _______________________________________________ >> Distutils-SIG maillist - [email protected] >> 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 - [email protected] > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
