Fwd: Using MSH Paris Nord server

[John Mandereau]

---------- Forwarded message ----------
From: John Mandereau <address@hidden>
Date: 2012/7/30
Subject: Re: Using MSH Paris Nord server
To: David Kastrup <address@hidden>


2012/7/30 David Kastrup <address@hidden>:
> 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