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

git-format-patch formatted patches attached to bugzilla is the only way
to contribute to m2e and I generally review contributions for the next
milestone build.

So my statement was strictly related to accepting contributions through
gerrit or any other means except bugzilla for that matter. I simply fail
to see what benefits gerrit can bring to m2e.

We have extremely low level of contributions. Learning gerrit is yet
another barrier a contributor would need to cross and I don't want it to
deter any prospects. Multiple contribution channels are harder to
monitor and make it more likely for contributions to be overlooked. Last
thing I want is for somebody to make a contribution through gerrit just
to see it slip through the cracks, go stale and require rework.

I do like gerrit and find it more useful code review tool than github
pull-requests for example, but I do not believe m2e needs more than one
way to contribution.

--
Regards,
Igor

On 2013-10-04 12:25 PM, Ed Merks wrote:
Igor,

I think folks generally should have a choice about using gerrit, but I'm
wondering if you're statement below is stronger.   I.e., do you mean
"m2e has no plans to accept contributions"?   If the project intends to
accept contributions and the source is maintained in a git repo, I'm not
sure I understand the "gerrit" qualification in your statement.   Gerrit
makes contributions easier to provide *and *easier to consume...  I also
wonder, who do you think specifically will be confused by gerrit
enablement?  The commiters? The contributors?  Why?  Do you think gerrit
itself is confusing?


On 04/10/2013 6:08 PM, Igor Fedorenko wrote:
m2e has no plans to accept gerrit contributions, at least not for now.
Having gerring enabled for m2e will be confusing.

--
Regards,
Igor


On 2013-10-04 10:22 AM, Doug Schaefer wrote:
I almost wonder if we should just enable Gerrit for all projects. That's
what we do internally here for all git repos that feed into product.
It's great for all the reasons you mention Ed.

The thing I like most about it is the verification jobs in co-ordination
with Hudson. You have so much more confidence when a change request is
sitting there knowing it has passed the JUnit run. I'm going to set that
up for CDT ASAP now that we have a HIPP instance.

Doug.

From: Ed Merks <ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>>
Date: Friday, 4 October, 2013 2:34 AM
To: "cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>"
<cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>>
Subject: Re: [cross-project-issues-dev] Making your project more
open…howto enable Gerrit

Miles,

If found migration to gerrit for EMF to be yet another painful step with
the migration from CVS to (E)git being the first one.  So incredibly
many magical settings and so many fundamentally important new concepts.
In the end though, I can definitely say that the pain is worth the
gain.  If you're even a little bit serious about opening up your project
up to external contribution and really expect it to happen, you're
missing the boat if you don't migrate to gerrit, which makes it
incredibly simple for *anyone* to develop a contribution, i.e., anyone
in the community can actually commit the changes in their local clone
back to your Eclipse gerrit clone, which can be configured to run your
build and run all your tests to confirm that the contribution doesn't
break the build or tests, and then you can simply review and accept the
contribution and by doing so, commit it into your real git repo.   Of
course gerrit is useful even just for the committers of a project,
allowing you to run a build and the tests before you commit back to the
real git repo, and naturally you can then do reviews easily and can run
further test the patches locally (once you learn more of the git magic
for how that works and don't shoot your own foot off in the process).


On 03/10/2013 8:19 PM, Miles Parker wrote:
Project leads:

I just tweeted about my disappointment in how many projects have not
yet enabled Gerrit. Chris A. pointed out that it wouldn't be a bad
thing to send a reminder to x-platform . All joking
aside[http://milesparker.blogspot.ca/2013/01/adopting-gerrit.html]
it really isn't hard, just click here!!

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Gerrit&short_desc=Enable%20Gerrit%20for%20my%20project


cheers,

Miles


Miles T. Parker | Tasktop Labs | Tasktop Technologies
email:miles.parker@xxxxxxxxxxx
web:http://tasktop.com   | blog:http://milesparker.blogspot.com

Committer: Eclipse Mylyn Reviews, R4E, Virgo
Lead: Eclipse Mylyn MFT, AMP

Are you passionate about innovation and excellence and interested in
joining our team? Tasktop, voted one of the Best Companies to Work
for in British Columbia, is hiring!

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orghttps://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

_______________________________________________
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