[Kde-scm-interest] Integrating Reviewboard with git branches

[Ian Monroe]

On Thu, Jan 24, 2013 at 1:25 PM, Jan Kundrát <jkt at flaska.net> wrote:
> Hi,
> I'd like to start a discussion about integrating the reviews and git more
> tightly. In particular, what I dislike about the reviewboard is that as a
> project maintainer, I have to carry the patches by hand and that the web
> interface has no information about what the parent commit is.
>
> I have some experience (as a user) with the qt-project's Gerrint instance.
> As I understand the past discussions on this topic, the sysadmins were
> opposed to giving push access to a random public-facing web server; there
> were also concerns about the ease of setup for the users (Gerrit ships with
> its own SSH server implementation, so that means either a custom port to set
> by all developers or weird setup for the sysadmins). Finally, it looks that
> the KDE community is now happy with the Reviewboard and its UI. I might not
> share this opinion, but I have no plans to push Gerrit when people are
> happier with the RB.
>
> What I would like to get, however, is the ability to:
>
> 1) Get access to each request as a git remote branch.
> 2) Be able to create and update reviews by pushing commits into some remote.
> 3) Keep full history of each and every version of each and every review
> request.
>
> In order to achieve this, here are a couple of points which I think shall
> describe the final state:
>
> - It should act as a tool which can be used, but is not required to be used.
> In contrast to the Qt-project's instance of Gerrit, there will be no
> requirement for commits to go through the review process.
>
> - The git branches shall be the authoritative source of data. I have seen
> reviews [1] where RB broke on patches containing binary data; the patches I
> downloaded from RB were different than what was sent to the RB and my git
> refused to apply them.
>
> - Each revision of the review request shall be reachable as a git head. I'm
> thinking of stuff like "reviews/108275/5".
>
> - In order to reach the last version of a particular review request, there
> shall be an alias. A good name might be simply "reviews/108275" (provided
> this is possible with git).
>
> - Creating reviews over the web shall be disabled. Reason: I don't know of
> any reliable way which will allow for 1) while allowing for web-submitted
> reviews as well. One could probably achieve that by creating the commit
> locally, but that looks like a lot of work which I'm absolutely not
> interested in doing.
>
> - Reviews shall be created simply by pushing data to a magic remote. In
> Gerrit, the custom is to call `git push gerrit HEAD:refs/for/master` which
> is as simple as one can get and as complicated as one could reasonably be
> asked remember; something which we should aim for, IMHO.
>
> - The system will have to distinguish between an updated review request and
> a completely new one. In Qt-project's Gerrit, this is achieved by a
> `commit-msg` hook which adds a Change-Id header to the commit message;
> Gerrit denies pushes which don't contain this header. If a commit has
> unrecognized Change-Id, a new review request gets created, otherwise the
> commit is used as a new revision of the existing request. The alternative is
> to remember where to push each time (so that pushes which go to
> refs/for/master create new requests but those which go to review/108275
> update said review request), but I'm willing to bet that people would be
> confusing these all the time. I know I would.
>
> - We will have to decide whether to always require that incoming reviews are
> against the latest commit in a given branch or whether we allow for changes
> based on older ones. I don't know what's best here.
>
> - Another question is how to deal with pushes which consist of several
> commits -- shall we refuse them, i.e. require all changes squashed into a
> single commit? I don't know how the comparable systems work.
>
> - It shall be probably noted that in a few years, a request for integrating
> the review system with automated continuous integration will surely arrive
> (if it doesn't arrive, I'll ask for that); we shall probably take this into
> account now.
>
> I've spoken with Ben the sysadmin about this topic on IRC earlier today and
> it seems to me that we share the opinion that it would be nice to be able to
> have the review system integrated with git more tightly. This mailing list
> seems like the best place to start the discussion about this topic and about
> how to get there.
>
> I'm not a KDE sysadmin, I'm just a maintainer of a small project who got
> frustrated enough by downloading the patches from web, guessing where to
> start a local branch, figuring out whether it's `git am` or `git apply` and
> copy-pasting the author's name, mail and the patch description to my
> favorite $EDITOR. I have also worked as a sysadmin for a couple of years, so
> I understand that the final solution will have to be maintainable and shall
> use as few weird components and hacks as possible, and that the sysadmin
> team will have the final word on whether $TOOL will get used or not.
>
> Let's discuss whether the goals I outlined above are worth the effort,
> whether they make sense to other people besides me and in case they make
> sense, let's talk about how to get there.
>
> And yes, I'm willing to help within the limited spare time and experience I
> have.

Your requirements sound sort of like Gerrit. ;)

You could also make use of the 'D' in DVCS, and use a service like
BitBucket to do the code reviews (which has a pull-request model,
works well for feature branches.)

Ian