Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit

btw. I will second that figuring out the right steps for submitting to gerrit driven projects is a pain compared to "raw" git. I know I got a few contributions
stranded/stalled because I had to fight with gerrit and borked custom instructions
on how to set it up.

I'm sure its pretty awesome once you've done your 5th or 10th contribution -
but the initial one is always tricky because of the custom git setup needed.

I would just be okey with both approaches so noobs can get in and if they
keep contributing spend the 10-15 minute it takes to get them up on submitting via
git.

/max

On Mon, Oct 07, 2013 at 10:06:56AM -0400, Igor Fedorenko wrote:
This was not about developers reviewing the changes. As I mentioned
upfront, I find gerrit very useful code review tool. I still believe
learning Gerrit is a berrier for prospect m2e contributors that are not
familiar with it. As long as m2e is not forced to accept contributions
through Gerrit, I am quite happy with Gerrit gaining popularity and it
is certainly on my radar, both for my other projects and m2e eventually.

--
Regards,
Igor

On 2013-10-07 9:51 AM, John Arthorne wrote:
Doug Schaefer <dschaefer@xxxxxxx> wrote on 10/04/2013 06:47:08 PM:

> 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 rebasing.

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.

John


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top