I heard about Gerrit at the recent PTP meeteing.
https://code.google.com/p/gerrit/
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.
Cheers, Steve
-----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.
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.
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.
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.
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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Roland Haas -
Steven R. Brandt