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. With kind regards, Jan [1] https://git.reviewboard.kde.org/r/108275/ -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
