Friday, January 4, 2013

Isn't Gerrit Ironic?

In my last post, I described the current state of Eclipse Gerrit adoption. If you haven't read that post, you might be as surprised as I was to find out how low it is: less than 15% of all Eclipse Projects are using Gerrit, and of those only a few are using it in a meaningful way.

Implementing Gerrit

That's understandable, because Gerrit is notoriously difficult to implement. But for those intrepid Eclipse Project Leads who don't mind getting their hands dirty, I'll take the time to detail all of the laborious steps:
  1. Click Here Now!!
  2. Replace the summary text "my project" with your project name
  3. Click "Submit Bug"
If you're an Eclipse Committer or Contributor, the steps are even simpler.
  1. Email a link to the instructions above to the project lead.
  2. (There isn't a step two.)
Of course, once you've enabled Gerrit for your project, there are all kinds of new processes and practices that you'll need to adopt:
  1. (There aren't any.)
Actually, while we're on the subject of code reviews, I thought it might be appropriate to try a little exercise. Please compare and contrast the following words:
  1. Facetiousness
  2. Sarcasm
  3. Irony
  4. Satire
Question: Did you feel the need to google any of these terms before answering? If so, you might be particularly interested in this link. I think the most important thing to learn there is don't debate irony.

On reflection, it turns out that the above exercise wasn't at all appropriate or relevant. I was just wasting your valuable time with an (arguably) mildly humorous segue. So let's just move on and forget it ever happened, shall we?

But before we do that, one more question: Which of the above words is most appropriate for describing this statement? (You may also choose "5. All of the above", "6. None of the above" or "7. Other: Just Stupid".)

Okay, enough [1, 2, 3, 4, Other]. Everyone knows that code reviews are serious business. Deadly serious business. Lives are at stake. Remember that the next time you blindly "Merge", Mr. or Ms. Reckless Coder!

Why Gerrit?

Really, the better question is "Why Not Gerrit?" -- or it would be, except that it would be really odd to introduce a query by proposing a negation. There really is nothing to lose*, except for poor traceability, error-filled code, and the ability to easily slip one past the Eclipse IP team. [Irony, I think. Or was that Satire?] Gerrit adoption can be as steep or as gradual as you want it to be -- I believe all of the default settings allow current committers to continue to commit straight to the Git repository, but I'm too lazy to check right now.

*There is one important exception; users of the Indolent Development methodology have found significant incompatibilities with Gerrit, as well as code reviews in general. It can especially interfere with practices 3 (The Random Walk) and 9 (Self-Expression). But the vast majority of Indolent adopters would have been too lazy/smart to read this far anyway.


The advantages to code review are manifest (translation: "everyone claims this, but I'm not sure if there is any hard evidence, and am too lazy to find out"), but include:
  1. Dramatic code quality improvement.
  2. Enforcement of common idioms and project standards.
  3. Clear workflows and defect traceability for contributions.
  4. Encouragement of intra-project collaboration and knowledge sharing.
  5. Greater inter-project transparency.
  6. Promotion of a more open and equitable Eclipse development process. (Back to that in a second.)
  7. A bunch of other stuff that, again, I'm too lazy to look up references for. But why am I always the one who has to do all of the work? If you're so damn curious, why don't you just Google "Gerrit Advantages" or something?


Okay, there are just a few disadvantages. Actually, so far I've compiled a list of 27 (I'm actually not joking), but I'll cover those in my next post. The reason I'm not sharing those now is that I really don't want to give you any information that might dissuade you from Clicking Here Now!! Sound fair?

An Eclipse Revolution?

The reason that I don't want to dissuade you from adopting Gerrit is because of point 6. Gerrit has the potential to profoundly democratize the contribution process for Eclipse. That's because -- when implemented fully and correctly -- Gerrit makes it every bit as annoying for Committers to get code in as it is for Contributors.

Hmmm...let's see if I can put a more positive spin on that....

For current committers -- even when fully implemented -- Gerrit really doesn't add much more of a burden than a straight commit, assuming that your project has decent oversight and communication. (You have that already, right?) And in many ways, it actually makes that process easier by automating some bits. The only additional step is that you have to actually go to the Gerrit review and click the submit button. At that point, you might say to yourself, "gee, maybe I should ask at least one other person what they think of this change before I inflict it on all of my consumers and users" -- but that's strictly between you and your conscience.

But for contributors*, the whole picture changes dramatically:

Before Gerrit

The traditional process involves creating (or taking on) a bugzilla bug, submitting patches (the process of creating an Eclipse patch is far from trivial), hoping someone would bother to take a look at the patch and make comments on it, digging through code trying to find the bits that those half-thoughout comments were referring to, merging and making changes to that patch, dealing with some rather opaque IP rituals, etc..

For the committer handling the patch, it mean manually applying the patch, dealing with any dependency changes or other build oddities, seeing if the darn thing actually builds, playing around with it, making half-thought out comments -- all of the time secretly hoping that the contributor would just give up and leave you in peace [Satire]. 

Git helps quite a bit, but it really doesn't help with the most important bits; managing builds, handling workflow, and tracking concerns.

After Gerrit

Now, if you want to contribute code to a Gerrit enabled project, things are much simpler. You create a bug, create a local topic branch, commit push them to gerrit, add project reviewers, and as changes come in, amend your local topic and push it again.

For the committer, it's even simpler. You fetch the commit (plug: using the rapidly improving Eclipse Mylyn Gerrit connector!), run it, suggest changes, wait for the user to get everything perfect, and then click one little submit button -- actually grateful that someone else fixed a bug or made an enhancement that you won't have to worry about anymore.

I really think that that advantage outweighs any other concerns, and it's why I'd really ask Project Leads to Click This Link Now!! Remember, you have nothing to lose!! Web-masters are standing by!! Believe it or not, that kind of badgering, repetition, naked-appeal-to-ego and strategic use of colour and obnoxious font styles has been repeatedly shown to work, even for very intelligent people like you. So Click Here Now!! (Actually, please don't do that unless you actually are a project committer.)

*For those of you who are not familiar with the Eclipse community, a "committer" is someone who is a formal member of a project and has been given commit rights to the repository, a "contributor" is all of the rest of us schmucks. The 99%'ers of the Eclipse universe, as it were.

Adopting Gerrit

Okay, things are a little more complex than I've made it sound, admittedly. But it really isn't that hard to get going on. Check out this wiki page, but don't let the details scare you.

Since Gerrit isn't actually all that easy to use properly, sometimes for purely social reasons but also because of purely technical ones, -- especially when it comes to reviews that depend on other reviews (run away! run away! while you still can!!) -- and since new users will need quite a bit of time to get used to it and to become familiar with all of the conventions, it might make sense to start out with simple workflows on relatively straightforward bugs just to get the hang of things and to allow your project process to evolve. But you can get a good survey of best practices by checking out EGit and Mylyn reviews as both projects have been doing this long enough to have evolved pretty mature processes. (Hint, poke around and find all of the comments from current committers pointing out all of the dumb things that new committers are doing wrong. Here's a good one.)

For project leads, you'll need to decide how err.. persuasive you want to be about getting people to adopt Gerrit. There may be some resistance from current committers, so there might be a need to get a little more active in encouraging adoption. Once you get a few committers rolling, my guess it that the inherent advantages along with the social/network pressures will kick in. Especially when existing committers start to see those contributions come pouring in.

At this point, I should probably make some suggestions about best practices, offer some tips and tricks and address some common pitfalls. But really, I'm feeling too lazy. Hey, it's Friday, okay? And I'm just back from holiday. I haven't really sunk into the demands of real work yet. Anyway, what are you doing reading this blog? Don't you have more important things to do?


If you're an Eclipse Project Lead, you've already won!!! Click This Link Now!!

And for all of you potential Eclipse Contributors out there, Mylyn, EGit, CDT, JDT/Platform and a bunch of other projects are already open for business!

No comments:

Post a Comment

Popular Posts

Recent Tweets

    follow me on Twitter