---------- Forwarded message ---------- From: John Mandereau <john.mander...@gmail.com> Date: 2012/7/30 Subject: Re: Using MSH Paris Nord server To: David Kastrup <d...@gnu.org>
2012/7/30 David Kastrup <d...@gnu.org>: > Here is what I see as the required steps: > > a) get a gerrit server set up > b) make test-patches.py deal with either Rietveld or Gerrit URLs for > testing > > At this point of time, it becomes feasible to manually create a Gerrit > review and have it go through our normal processes. > > c) make git-cl configurable so that it can optionally create Gerrit > reviews instead of Rietveld reviews. > > At this point of time, it becomes feasible to sensibly test one setup > against the other for a typical developer. > > d) document Gerrit operation of git-cl in the CG > > e) deprecate Rietveld use Right. I was about to submit patches the build system (cleaning traces of Stepmake as an installable, separate package, merging make and stepmake/stepmake, using git file list to roll source tarball, reduce make overhead by deleting useless makefiles in many subdirectories), but I think trying Gerrit has a higher priority, and it will be a good opportunity to test Gerrit on those patches (e.g. I'd be glad to see that Gerrit handles diffs with file renames, i.e. "git diff -M" on the command-line). > I don't see that feature comparisons from manuals will do much for > getting an actual hang of the respective advantages/disadvantages. At least it allows estimating them, I wanted to do this before diving into setting up Gerrit. Your message saves me the time and energy of writing a detailed review based on feature comparisons from manuals and previous discussions, which as you say would have far less value than an actual experiment with these tools/ > We know that the principal disadvantage of Rietveld is its inability to > deal with a patch sequence gracefully, and that one reviews tree changes > rather than commits (which would include commit messages, authors, > signoffs etc). Agreed. I experienced this too. > The base feature set other than that is comparable, but > figuring out how feasible the respective use cases will be can only be > done in practice. It seems from its manual that Gerrit doesn't provide as much email integration as Rietveld (e.g. replies by email get added to the review comments threads in the review server), but it might, and anyway this would not be terribly hard to add. However, a Gerrit setup for LilyPond alone will certainly help having a global eye on submitted patches, and avoid creating Google Code issues for patches that are not bug fixes. > I don't see that be can get by without at least > implementing b) in some manner, and we don't really need much of > "sufficient approval from core developers" for that. I was thinking of other tools, like ReviewBoard, but I find don't their issues system much useful; it has integration with Google Code, it seems to provide better Git integration than Rietveld, but less than Gerrit http://www.reviewboard.org/docs/manual/dev/faq/#does-review-board-support-git Well, we can integrate Gerrit with Google code through git-cl/test-patches, so ReviewBoard doesn't seem to win over Gerrit w.r.t. these two criteria. > Of course, if we later find that everybody finds Gerrit too cumbersome > to use, or if we get serious protests against reviews being even placed > there, the work invested up to that point may be wasted. Wasting time setting up Gerrit was my concern, but now it's no longer. I'll chime in back when I have done steps a) and b). John _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
