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
|
