On Jul 26, 2012, at 7:04 PM, MZMcBride <z(a)mzmcbride.com> wrote:
Rob Lanphier wrote:
A few of us are planning to meet Monday afternoon
to figure out exactly
what the rest of the process looks like, so that first deadline is going to
be very important for understanding how many options we're truly
considering.
Well, at least you're being open about not being open.
That's funny, because my experience is the exact opposite: this meeting is not in my
calendar and I breathed a sigh of relief!
It's somewhat ironic that you have a group of
people who regularly champion
the virtues of open source software ("you can hack the code!") who have
picked a software solution that's (apparently) nearly impossible to modify.
Even eliminating Gerrit's vomit color scheme would be a vast improvement,
but as I understand it, even basic CSS changes are a no-go with Gerrit.
Gerrit has templating support so basic CSS changes are not difficult and require no
pushes to upstream Gerrit. Delta one strange thing in that the load order of the cascade
in Gerrit is… wrong. My arguments with Gerrit are in fancier scripting UI that requires
delving into GWT to get done. Chad mentioned that virtually nobody has played with either
yet.
I'm lost as to how Gerrit was ever considered an
option previously and how
it's still an option on the table today, given its apparent inflexibility.
Say what you will about MediaWiki's CodeReview extension, but on its worst
day, it never garnered as much resentment as Gerrit.
The wiki page outlines exactly what went into the decision.
For instance, I like Phabricator. However very few of the requirements listed when this
was discussed (in March) were in Phabricator so I understand why Gerrit was chosen even if
I have a personal dislike for it. Phabricator has a high velocity of new features and
support (actually about 2x Gerrit) and that is now changes. However, even so, that
isn't the case (yet).
Also, consider that even if that is the case, it's neither Features engineers nor the
community will be inplementing/maintaining whatever solution is used. The maintainers will
be in Platform and Ops.
Now we can argue over whether the wiki page's criterias were the "right
ones." (For instance, should the WMF adopt the Git/GitHub philosophy of un-gated
reviews?) But since those criteria come from the practical reality on how code review is
actually done and integrated currently, that's a different argument entirely to what
code review tool is best for how we currently use it.
Gerrit won simply because it is designed to work the same way we were currently working…
warts and all. But the landscape is changing and it's time to re-evaluate if a course
correction is in order. Hopefully this won't be the last (if only because I don't
think any other system is going to beat Gerrit spec-for-spec ATM).