Doug Schaefer <dschaefer@xxxxxxx> wrote on 10/04/2013
> No they're not. I can't see any way that patches in bugzilla are easier
> than gerrit. It's one "Push to Gerrit" and one "Publish
and Submit" clicks
> away from getting a contribution made and accepted.
The "Submit" button is a bit dangerous that
way. For most changes you can't thoroughly review it without trying it
out, which means loading it into your local workspace. For a bugzilla patch
you can paste it directly into the navigator so it really can't be beat
(about four keystrokes for the whole process to copy/paste the patch).
Whether you use UI or command line, Gerrit is a bit more work there.
But really which is mechanically easier is not the
point with Gerrit. By creating a branch for each change, Gerrit is setting
up a much richer structure that will naturally be a bit more work but also
much more powerful. Gerrit really shines on big changes that take several
iterations. For example comparing the latest patch against either master
or any previous draft is very easy to do in Gerrit, and very difficult
with patch files. Being able to flag each file as reviewed so you can later
come back to it is also really nice. And to me the most powerful feature
is the ability to rebase the patch directly from within Gerrit, which makes
it very easy to keep patches in sync with master, unlike bugzilla patches
that tend to rot quickly and usually the contributor is asked to do the
So my advice would be, even if Gerrit feels like more
work for you because you have mastered your old bugzilla patch workflow,
it's worth giving it a try. With email notifications and a handy dashboard
it really isn't more work to monitor and accept contributions on both channels.
I really don't think Gerrit needs to be forced on projects though if they
aren't seeing the benefit yet.