On Thu, Jan 24, 2013 at 1:25 PM, Jan Kundrát <j...@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 _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest