Heya,
Interesting points. Looking at bzr/launchpad it has a nifty feature: email-in bzr bundle. Bzr bundle is like git-format-patch, however one can pull from it rather than merely apply. (Essentially it has bencoded objects at the end of the patch). The difference is complete round-trip (identical commit id, preserved gpg signed commits). And launchpad accepts emailed in bundles, constructs identical branch and can create merge proposal from it (pull request) which is then managed by email for the originator. (Not sure about account, I believe a ghost account is created that originator can later "claim" if they wish to sign up). That's quite good, however the coments are still managed in "server-side" database.
Gerrit has another cool thing. When I backed up git repositories, dropped the instance and moved the repos back in, I was surprised to find all of the reviews and comments back in place. Turns out all reviews are stored as git notes essentially.
I hate that format-patch/am workflow does not preserve git commit-id and gpg signatures. Request-pull workflow inflicts the pain of publicly hosting git repository and keeping it accessible. Email is better - cause once one receive it one can process it offline/disconnected. Loosing information is not acceptable.
Ideally we should be able to support unauthenticated, distributed/synchronised, lossless code review. Email round tripping is a must, potentially generating git repo, store review comments as git notes, and allow unauthenticated clone of that. Syndicating reviews would be cool as well - that is allow pulling/mirroring reviews in from satellite git-review repos. (E.g. consider a patch posted to two mailing lists, both have active review on it, both generating review-git-repos, if one clones both one should get combined review thread. Or if Admins actively mirror each other, a combined review should be accessible).
Then I would expect e.g. Jenkins review manage it's own reviews of things, that one can choose to combine with "human" review. And so on.
Pura Vida!
- Dimitri.
On 19 Apr 2015 2:01 am, "Ben Finney" <ben+debian@benfinney.id.au> wrote:
>
> Neil Williams <codehelp@debian.org> writes:
>
> > On Sat, 18 Apr 2015 17:55:17 +1000
> > Ben Finney <ben+debian@benfinney.id.au> wrote:
> >
> > > GitHub's pull request feature is proprietary to GitHub, it can only
> > > work between repositories hosted inside the GitHub silo, and any
> > > project using that feature is thereby locking its workflow to the
> > > single-vendor GitHub service.
> >
> > Not true. Simply and completely untrue.
> >
> > The pull request exists on github, fine.
>
> How can a collaborator Alice, with no GitHub account, get the pull
> request?
>
> > I can either choose to manually pick that out of the github interface
>
> I don't know what this means. How does that interact with the repository
> a collaborator Alice, with no GitHub account, is using with standard
> Git?
>
> > or I can choose to use my github account to merge that pull request
> > into a local branch.
>
> So this option supports my point that the GitHub pull request is siloed,
> and one must have an account with the single vendor in order to access
> it.
>
> > > Git repositories outside GitHub cannot interact with the GitHub pull
> > > request workflow using Git's own features.
> >
> > Untrue. I use github and git.linaro.org side by side and have applied
> > github pull requests as reviews on review.linaro.org
>
> How does a person Bob, using their GitHub repository, send a pull
> request to Carol using only their ‘review.linaro.org’ repository?
>
> Does Carol need a GitHub account and repository hosted at GitHub? If so,
> that's the point I'm making: GitHub's pull request can only be received
> and handled by another GitHub repository.
>
> > > They have chosen (or have never been aware they made the choice) to
> > > make it much harder to interact with them using the existing,
> > > standard, federated Git ‘request-pull’ feature, instead opting to
> > > exclude anyone who doesn't want an account on a specific vendor's
> > > service.
> >
> > Sorry, that makes no sense. Working with github as a second remote is
> > trivial.
>
> How does a collaborator Alice, with no GitHub account, access Bob's
> repository on GitHub and use the standard ‘git-request-pull’ to make a
> pull request to Bob? How does this interact with the GitHub pull request
> feature?
>
> How does Bob make a pull request to Alice, using GitHub's pull request
> feature, such that Alice can handle it using standard Git?
>
> Your descriptions so far seem to support the position that Git
> ‘request-pull’ is equal for all peers, is incompatible with a
> workflow based on GitHub pull requests, and that GitHub pull requests
> cannot be received and handled using standard Git commands.
>
> My point is to refute the notion that GitHub pull requests are open and
> equal for all peer repositories. Please show specifically where I'm
> wrong on that.
>
> --
> \ “Don't worry about people stealing your ideas. If your ideas |
> `\ are any good, you'll have to ram them down people's throats.” |
> _o__) —Howard Aiken |
> Ben Finney
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 85wq18pk5q.fsf@benfinney.id.au">https://lists.debian.org/[🔎] 85wq18pk5q.fsf@benfinney.id.au
>