Gerrit Review on multiple commits and on feature level
srinivas chary
Hi
I have two scenarios to install on my new Gerrit setup. please advise.
1. How send one review request for multiple commits done by the developer. Instead
of sending one review for each commit, need to accumulate all commits and send
for review.
2. An option in Gerrit to submit reviews based on feature wise. let say a feature is implemented totally in one folder of a project and requirement is to send for review only when there is a change in the folder content. Also based on directory or folder changes, a way to set different reviewers.
3. we have 20 plus developers. For each developer we want to set different reviewer from the same team. How to configure this peer to peer reviewers.
we have these scenarios to achieve with Gerrit. Let me know the feasibilties and solutions to achieve these.
Magnus Bäck
> 1. How send one review request for multiple commits done by the
> developer. Instead of sending one review for each commit, need
> to accumulate all commits and send for review.
have been accepted upstream (and by now those patches are seriously
dated). You could use the topic feature to make it easy to discover all
related changes, but there's no way to review that set of changes as a
whole.
> 2. An option in Gerrit to submit reviews based on feature wise. let
> say a feature is implemented totally in one folder of a project and
> requirement is to send for review only when there is a change in the
> folder content.
understand this one.
> Also based on directory or folder changes, a way to set different
> reviewers.
touching different subdirectories.
> 3. we have 20 plus developers. For each developer we want to set
> different reviewer from the same team. How to configure this peer
> to peer reviewers.
than the designated reviewer of an author to approve the change?
See below.
http://gerrit-documentation.googlecode.com/svn/Documentation/2.5/prolog-cookbook.html#_example_13_master_and_apprentice
Or do you just want Gerrit to automatically add the designated reviewer
when a user uploads a change?
--
Magnus Bäck
ba...@google.com
Mark Derricutt
I.e. I want my coworker to review, as a whole - the commits 1,2,3,4 and 5 in the API, Server, and Client projects.
Gerrit already uses Change-Id: xxxxxx, I'm wondering if something like "Change-Tag" could be added, as a simple manner of tagging/labeling disparate sets of commits, similar to how one may #hashtag a twitter post, or Flickr photo.
In the UI something like this could simply manifest as a new search filter, and row in the commit details. Is this something that the current plugin architecture could possibly provide, or would this need something lower level?
Magnus Bäck wrote:
> 1. How send one review request for multiple commits done by the
> developer. Instead of sending one review for each commit, need
> to accumulate all commits and send for review.
One company has forked Gerrit to add this functionality, but no patches
have been accepted upstream (and by now those patches are seriously
dated). You could use the topic feature to make it easy to discover all
related changes, but there's no way to review that set of changes as a
whole.
Thomas Swindells (tswindel)
I agree, this functionality to review many changes at once would be extremely useful.
This is partly why I’m pushing to get proper reviewing of merge commits in at the hack-a-thon, this at least provides a single project mechanism to review a bunch of commits (via branching and merging). Something more seamless would of course be even better, hopefully we’ll be able to thrash something out and make some progress at the hack-a-thon.
It’s probably an interesting question as to how topics, branches and potentially tags overlap and intersect with each other. All of them can be used nu users to signify a group of changes across projects which are related. The potential problem with all of them is how they are used on a shared Gerrit server used by many teams. Having a new concept is probably the best approach as it at least doesn’t break existing uses. The key thing is many teams may all decide to use a release1.1 branch or topic on completely different products and will have the expectation that this should keep working.
Thomas
--
--
To unsubscribe, email
repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Magnus Bäck
> I've been wanting something similar to this, but with the added
> complexity of somehow grouping those commits/reviews across multiple
> projects.
>
> I.e. I want my coworker to review, as a whole - the commits 1,2,3,4
> and 5 in the API, Server, and Client projects.
>
> Gerrit already uses Change-Id: xxxxxx, I'm wondering if something
> like "Change-Tag" could be added, as a simple manner of
> tagging/labeling disparate sets of commits, similar to how one may
> #hashtag a twitter post, or Flickr photo.
>
> In the UI something like this could simply manifest as a new search
> filter, and row in the commit details. Is this something that the
> current plugin architecture could possibly provide, or would this
> need something lower level?
asking for?
--
Magnus Bäck
ba...@google.com
Thomas Swindells (tswindel)
> -----Original Message-----
> From: repo-d...@googlegroups.com [mailto:repo-
> dis...@googlegroups.com] On Behalf Of Magnus Bäck
> Sent: 01 May 2013 14:10
> To: repo-d...@googlegroups.com
> Subject: Re: Gerrit Review on multiple commits and on feature level
>
We of course could just say 'tough' to this scenario, but I imagine it's going to be fairly common.
Thomas
Magnus Bäck
> > Wouldn't Gerrit's topic feature be sufficiently close to what you're
> > asking for?
>
> That may not work on existing installations - Team A and Team B may
> both already have a 'ui-improvement' topic which aren't at all related
> to each other.
> We of course could just say 'tough' to this scenario, but I imagine
> it's going to be fairly common.
limitation you're describing should exist also with what was suggested
(Change-Tag footer in commit message).
--
Magnus Bäck
ba...@google.com
Thomas Swindells (tswindel)
> -----Original Message-----
> From: repo-d...@googlegroups.com [mailto:repo-
> dis...@googlegroups.com] On Behalf Of Magnus Bäck
> Sent: 01 May 2013 15:39
> To: repo-d...@googlegroups.com
> Subject: Re: Gerrit Review on multiple commits and on feature level
>
But I'm not entirely happy with the prospect of creating multiple ways of doing almost the
same thing either. This is one of those annoying trade-off situations where whatever you
do is wrong!
We don't currently use topics within our company so I'm happy for the meaning to subtly change,
from a quick browse of the documentation it is very vague as to what topics are for anyway:
"To include a short tag associated with all of the changes in the same group, such as the local topic
branch name, append it after the destination branch name. In this example the short topic tag
driver/i42 will be saved on each change this push creates or updates:
git push ssh://john...@git.example.com:29418/kernel/common HEAD:refs/for/experimental%topic=driver/i42"
How much do other people use topics and for what purpose? Are they to group together a set
of changes that should be reviewed together, or are they more of a longer lived tag which doesn't
really imply grouping?
Mark Derricutt
Wouldn't Gerrit's topic feature be sufficiently close to what you're
asking for?
Our workflow at work involves using git-flow feature branches named after tickets in the bug track, so say SMX3-3232-some-fix, often I use that same local branch name across my various repositories, using that as the topic seems to work well, as its usually only one person working on a ticket ( thus no over lap ).
Currently we configure out .git/config with:
[remote "for-review"]
url = gerrit:dev/smx3-standardreports
fetch = +refs/heads/*:refs/remotes/for-review/*
push = HEAD:refs/for/develop/SMX3-5789-dbtables
so we just "git push for-review", so adding the topic to the end of the push= works, but would be a manual change to config each time, tho now I know how this works I can look into a better way around that, I'm currently thinking of a git-review script to put on my path which assembles the url+push+topic from the config and current branch name - which should work fine.
Thanks for the pointer to topics!
Mark