On Thu, 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.
Well, it's very likely the staff that will end up doing the work.
Also, we're meeting to figure out the rest of the process. We're not
making a decision. So far the entire process has been in the open, and
will continue to be so. Good to see you're assuming good faith, though
;).
You've already admitted that you don't use Gerrit, so do you have a
really large stake in this?
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.
A few people on this list have gone so far as to say "but the next release
is always better!" I realize I was being a bit tongue-in-cheek by suggesting
earlier that Gerrit's UI was developed by Microsoft, but to have developers
now spouting corporate justifications for shitty software? I'm left to
wonder what the hell happened.
Every release *has* been much better and the releases are often, and
that's a great thing. It's not a corporate justification, it's
reality. Having a really responsive and active upstream is awesome.
We have other pieces of infrastructure that are similar. Take bugzilla
for instance. We don't really modify it much, we don't think its
interface is great, but we're thankful when upstream changes help us.
Also, there's no really great alternative to bugzilla. We've had
numerous discussions about replacing bugzilla, and the discussion
always dies out because the alternatives are just as bad or worse. We
use what works and generally only change things when there's a really
strong justification for doing so.
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.
It was considered because it worked and it was better than any
alternatives we found. It was easy to integrate into our toolsets with
minimal effort. Other solutions would have required extensive code
changes which we honestly don't have time to make.
I know people complain about Gerrit a lot, but I personally find it
much better than our previous toolset. We couldn't have reasonably
opened our ops infrastructure without some form of pre-merge review.
Also, we can much more easily give people accounts. In our previous
workflow SVN access required developers to have prior code examples,
and we have to approve them to ensure they wouldn't submit insecure
code. We can just give people accounts now, and we eventually allow
people to self-register as well. In fact, this is one of my top goals
after upgrading openstack and adding a new Labs zone in eqiad.
- Ryan