On 11 August 2013 12:26, info@gno.de wrote:
Yes I aggree with pre-commit code review. But there also could be remaining bugs after the code was pushed and identified to that code.
Yes, that is true. I think it would be best to have them as bugs, especially after we migrate to bugzilla, which would make linking to bugs/patches easy.
Anyway I've additional questions to that gerrit workflow:
1st: Is there any way to download these patches for review purposes and merge it to the working copy. It is very uncomfortable do do that by hand and in some cases it is necessary to test the code snippets and not only read it.
Using git-review:
git review -d <change number>
which would check out the change. If you need to make any changes, you can do this by editing the files, then
git commit --amend <files> git review
which then will upload a new changeset to gerrit.
I'm not really sure though how you can do this under windows easily, as tortoisegit doesn't seem to have any git-review capabilities...
2nd: What is the meaning of the scorings "verified" vs. "Code-Review"
In our case, "Verified" is used by jenkins-bot to set 'OK' or 'not OK' after pep8 validation (and in the future unit tests). Code-Review is used by the human reviewers as approval. To merge, both have to be 'OK' (+2).
Best, Merlijn