John Mandereau <john.mander...@gmail.com> writes: > 2012/7/23 John Mandereau <john.mander...@gmail.com>: >> Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto: >>> Maybe running gerrit on it would be an option? >> >> This sounds an excellent idea. > > Wait, there has already been much discussion about patch review tools, > much of it happened when I was completely away. Before diving into > setting up Gerrit, I'd like to summarize the pros and cons of > Rietveld+Google Code Issues+Patchy (current system), Gerrit, > ReviewBoard, and others, judging on features that have been discussed > on this list. Be warned that I tend to prefer Gerrit, but I don't want > to spend time setting it before a contradictory assesment (summarizing > previous discussion and comparing the features of these tools > advertized by their manuals) and sufficient approval from core > developers.
That implies having to make a choice before thinking about switching. I don't see that this makes much sense. 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 I don't see that feature comparisons from manuals will do much for getting an actual hang of the respective advantages/disadvantages. 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). 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. 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. 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. But I don't see how we can even attempt to arrive at a decision before getting there. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
