On Jul 26, 2012, at 7:04 PM, MZMcBride z@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).