On 7 March 2012 02:13, Chad <innocentkiller(a)gmail.com> wrote:
On Tue, Mar 6, 2012 at 6:42 PM, K. Peachey
On Wed, Mar 7, 2012 at 5:20 AM, Diederik van
Liere <dvanliere(a)gmail.com> wrote:
My concern is not about the UI of Gerrit, I know
it's popular within
WMF to say that it's UI sucks but I don't think that's the case and
even if it was an issue it's only minor.
We are changing from a CR system where everything (or atleast almost
everything) was displayed on a single (and non confusing) page to a
system that to plainly put it, is a clusterfuck of confusing (And i'm
known for choosing the more time consuming/evil/painful methods of
I'll be the first to admit that Gerrit may not be the single most intuitive
piece of software. But to call it a clusterfuck is doing it a disservice.
The learning curve is steeper than our home-grown CodeReview tool,
but I honestly don't think it's insurmountable.
I've said to many people that I have concerns about this move, so I'm
trying to explain what concerns me and asking what are the benefits
Usually when something is replaced with more complicated solution,
there are some needs it addressed or new benefits it brings.
But honestly, I'm quite happy with the current tools with all their
shortcomings. We actually get stuff done, even if breaking lots of
things while doing that and only noticing so late that the only option
is to fix it as well as possible.
So what are the benefits of Git+Gerrit+Gated trunk? I can think many
tasks it makes harder (for me), but I can hardly think any benefits
The ops/lead engineers might be happy when they get a stable master.
But if that is because development slows down due to increased hurdles
getting stuff into the master, is it really a benefit at all? The
"wait until you can't revert" model above is certainly not going to
work with gated trunk, and I doubt that anybody suddenly starts
reviewing those big refactorings or commits to the areas of codebase
nobody really knows when we switch over.
Our code base is very old and complex to the extend that many areas of
it are not understood but only few developers, if anyone. Yet those
few developers do not have the time to review patches or improve those
areas of the code to the extend that other developers would be able to
learn them and work on them. We need to keep modernizing our core
code, making it less complex and designing good interfaces. I think
the current state of core is already limiting innovation in
Rather than solving our review problem, I think GiGeGa might even make
it worse by slowing the type development work mentioned above.
So once again, what are the benefits for me?
The advantages listed at
don't apply to
* I rarely work off-line
* I spend about 30 minutes a week merging code (this is supposed to be easier)
* I spend around 10 hours a week reviewing code (this is going to be
much more difficult)
* I do many commits per day (not easier, don't know yet how much more difficult)
From this I gather the people who benefit most are
people who just
want to do some small fix, fire it and forget it and people who
lots of time merging or traveling.
One benefit I would like to see is that WMF would feel the pain needed
to get the code of its various projects reviewed. It has many projects
with single or few developers but nobody is assigned to do the code
review on them from the very beginning. I'm afraid it will just find
some way around requirement.