Re: [gentoo-dev] Re: Gentoo-hosted code review

2015-11-02 Thread Alexander Berntsen
Hash: SHA512

On 02/11/15 14:24, Michael Palimaka wrote:
> Which workflow do you mean? Most features seem optional, allowing 
> people to work as they wish.
It's been a while since I looked at it outside of GHC, so please bear
in mind these things might have changed since then.

The major obstacle for my company is that it doesn't work if you want
to enforce (or even just allow) that author /= committer. Furthermore,
when I used it it broke author dates and GPG signing. Lastly, you
can't review a patch series -- you'll need either to squash the
patches (which is done automatically), or review them independently.

As for the workflow it to some degrees enforces (and certainly is
optimised for), I don't have a link readily available. I could ask
Austin from GHC about it if you are very curious (he's the one who
sent it to me some time ago).

Also, FWIW, I very much dislike arcanist. Herbert from the GHC team is
working on a lite version[0] that I think might end up more pleasant.
(However, it will likely be optimised for GHC.)

- -- 
Version: GnuPG v2


Re: [gentoo-dev] Re: Gentoo-hosted code review

2015-11-02 Thread Kristian Fiskerstrand
Hash: SHA512

On 11/02/2015 01:26 PM, Michael Palimaka wrote:
> On 02/11/15 09:07, Michael Orlitzky wrote:
>> On 11/01/2015 12:44 PM, Michael Palimaka wrote:
>>> There's been a lot of discussion about relying on GitHub for 
>>> pull requests and code review and such, so I have set up a 
>>> Phabricator instance against gentoo.git to see how a free 
>>> alternative might work.
>>> ...
>>> What do you think?
>> Thanks for working on this. I personally didn't like Phabricator 
>> very much when I used it, but I'm glad someone is trying out
>> code review platforms. I could live with it.
>> The big question for me is, does the apache user have write 
>> access to the gentoo.git repo? If it does, are we all
>> comfortable with allowing a bajillion-line PHP application
>> unchecked access to our repo? That's the serious problem I see
>> with Gerrit, Gitlab and the rest.
> It supports repository hosting, but that is optional. I too prefer 
> the idea of keeping the repo and other tools separate, so the demo 
> is running again plain anongit (and that seems to work fine).

The way I see it, keeping review and committing/pushing separate is a
good thing, and removes a lot of the concerns about hosting a review
platform as it is sufficient with read-access to repositories.

Thanks for showing at least one of the alternatives.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


Re: [gentoo-dev] Re: Gentoo-hosted code review

2015-11-02 Thread Dirkjan Ochtman
On Mon, Nov 2, 2015 at 2:04 PM, Kristian Fiskerstrand  wrote:
> The way I see it, keeping review and committing/pushing separate is a
> good thing, and removes a lot of the concerns about hosting a review
> platform as it is sufficient with read-access to repositories.
> Thanks for showing at least one of the alternatives.


FWIW, I think most of the innovation in review UX (insofar as there is
any) is happening on ReviewBoard, which is another FOSS review-only
tool, written on top of Django. A Python-based app might also be more
hackable for the Gentoo dev audience and possibly more
security-sensible. I know that Mozilla is starting to deploy it quite



Re: [gentoo-dev] Re: Gentoo-hosted code review

2015-11-02 Thread Patrice Clement
Monday 02 Nov 2015 09:29:48, Duncan wrote :
> Patrice Clement posted on Mon, 02 Nov 2015 09:33:49 +0100 as excerpted:
> > [gerrit]
> > 
> > Anyway, just my 2 cents on the topic. Have a look and you'll see in
> > terms of features, I think it's on a par with Github. And it's open
> > source. ;)
> FWIW from previous gerrit suggestions...
> The problem there is ... java, along with the maintenance and security 
> issues it brings when run on a publicly accessible server where java is 
> otherwise unnecessary.  (IIRC, at least one infra person said it's a hard 
> no on java running on gentoo infra, period, as it simply cannot be done 
> correctly and safely with the resources available.  Tho I'm not 100% sure 
> IRC on that one.)
> #2 problem, as with several code-review products, is the security issue 
> of the huge stack of code (regardless of language) on a web server, with 
> direct single-user write access to the tree.  If it were a different user 
> for each dev account so unconditional write access wasn't a monolithic 
> grant...
> Now if a one-way repo sync is done to the tree gerrit accesses from 
> gentoo-master, not reversed, sandboxing the tree gerrit has access too, 
> the problem is lessened to some degree, but of course that dramatically 
> lessens the usefulness as well, since the reviewed code must then be 
> checked back into the main tree manually.
> Which would seem to be one potential positive for phabricator, since at 
> least from the bit here in-thread, it appears to be review-only, no 
> direct commit access, thereby eliminating at least that security threat.
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman

By reading your answer, I'm not sure if it is clear or obvious for most users 
the workflow between the Gentoo infra <-> Github infra functions so maybe we
should explain it one more time:

1) Gentoo developers receive notifications (emails) from Github that somebody's
  sent a PR and would like to merge it into the main repo
2) They go over to and checkout the PR
3a) Sometimes (often), the PR has tons of errors and doesn't respect our coding
  standards and suddenly, we get a zillion notifications that mgorny and
  hasufell are peer-reviewing the PR ;)
3b) Sometimes the PR is spot on, the ebuild(s) submitted is (are) flawless, we
  merge it.
4) How do we merge it? We do *NOT* make use of the "Merge" button Github offers
(and never will). Why? Changes would get lost in the wind if we did so, since
the repository sitting on the Github infra is merely a mirror. Instead, we pull
each PR into our own local copy of the Gentoo git repository hosted at and then merge them. 

See: and

Think of Github as a nice and fancy UI to bridge the gap between developers and
those allergic to a console and used to a browser.

Now, with this explanation out of the way, I'm not sure what you mean by the
"security threat" issue you've brought up your email. 

Gerrit is a code-review web platform that CAN allow commits to be merged, but
this privilege has to be granted to specific users (like Github). It is really
up to us and how infra want to manage merging. It doesn't make Gerrit less or
more secure IMHO. This is a biased argument.

Patrice Clement
Gentoo Linux developer