[Users] Gerrit

[Steven R. Brandt]

On 09/16/2013 02:46 PM, Roland Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello all,
>
>> Gerrit manages the process of code reviewing in git, and has a lot
>> of customization. You can set things up so that no one can push to
>> the main branch unless their change has been reviewed. You can make
>> rules like, one senior developer and two junior developers must
>> review, etc. By helping to enforce code reviews, Gerrit helps to
>> increase code quality, and helps to train junior developers in
>> understanding the codebase. I think it might be a good alternative
>> to Trac.
> You mean replacing Trac with Gerrit? Personally I would try to avoid
> changing the user-facing interface of our bug tracking system. There
> seem to be some review systems that plug into Trac eg
> http://trac-hacks.org/wiki/PeerReviewPlugin that try to formalize the
> review process. Our current method ie. setting the "review" state and
> waiting for a "Please apply" would be replaced by some more formalized
> method.
That may be just as good. I don't know. I was pretty excited by
the Gerrit demo. :)
>
> If it is possible to run Gerrit as a review system only (and somehow
> hook it up into Trac) then I'd find that a better approach.
>
> I do not think that restricting commits to only reviewed commits is a
> good idea (others may very well disagree). At least not for projects
> that have an active and (essentially) single author like Carpet or Kranc.
I think that a system like Gerrit might help to correct the problem
of single author repos. By being disciplined about doing code reviews
one spreads knowledge through the community. It worked for the
software I developed in private industry (where the discipline was
maintained by a boss saying, "You must!").

I think a system which enforces code reviews could be a tool to
help us keep our intended resolve. I don't actually know whether it
would work out, and I wouldn't suggest making a sudden
sweeping change.

First the review system would be optional, and then if people liked
it and it worked, it could be made official.
>
> If there is anything I do not like about the current procedure it is
> not actually the way that reviews are handled but more the issue that
> sometimes review requests sit idle for a long time.
>
> Similarly if the goal is to reduce the number of open tickets, we
> could adopt SpEC's practice of having explicit ticket review code
> calls where each ticket is discussed in a 5min slot (enforced) and at
> the very least assigned to a person.
The goals of this system are (1) higher quality code, usually two
sets of eyes on any change is better; and (2) better spread of
code knowledge, at least initially, a reviewer has to learn about
what's being done to comment on it. Imagine what would happen
to us if Erik (or Ian) was seriously inured or decided he wanted
to go tell stories for a living.
>
> Yours,
> Roland
>
> - -- 
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from http://keys.gnupg.net.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iEYEARECAAYFAlI3YBEACgkQTiFSTN7SboWueQCcCA3g4t5OJdjFonDnBjU7NTOq
> X1MAoIDiNy7R0tIgWYHsIFDja8KOvG4S
> =lVTG
> -----END PGP SIGNATURE-----
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users