[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using MSH Paris Nord server

From: David Kastrup
Subject: Re: Using MSH Paris Nord server
Date: Mon, 30 Jul 2012 12:42:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

John Mandereau <address@hidden> writes:

> 2012/7/23 John Mandereau <address@hidden>:
>> 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 deal with either Rietveld or Gerrit URLs for

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]