Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Hi, The Eclipse wiki describes all possible options for Gerrit setup and configuration, which is good but* *I think this makes is a bit harder for new contributors to setup the Gerrit connection up. I tried to summarize the simple setup for Gerrit contributions for Eclipse here: http://www.vogella.com/articles/Gerrit/article.html#eclipsegerritcontribution using Platform UI as example. Best regards, Lars 2013/10/5 Doug Schaefer dschae...@qnx.com Yes, that generally how we work too. We're big users of Gerrit internally here on Momentics. That's generally how things go. Discussions happen in our bug system (JIRA), but only comments on the code happen in Gerrit. In all the bugzilla's I've looked at over the years, there actually weren't that many detailed code discussions there anyway. Gerrit lets you attach comments right to the lines. Bugzilla has never claimed to be a code review tool. BTW, great to hear that about SWTbot. You can't help but think making contribution and review easier is healthy for a project. Doug. From: Mickael Istria mist...@redhat.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 5:24 PM To: cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit On 10/04/2013 09:00 PM, Ian Bull wrote: I'm not sure how the more experienced Gerrit users deal with this. I don't consider myself as an expert, but I generally try to keep discussion related to use-case, test scenario and possible designs on the Bugzilla, and put discussions about code itself of Gerrit as it allows inline comments in contributions, versioning and comparison of patches, easy fetch, automatic CI check. When the discussion on Bugzilla has come to a point where it becomes possible to write code, I put a link to a Gerrit contrib on Bugzilla. Then most of the discussion happens on the Gerrit patch, and when it is done, it gets merged and then we can close the Bugzilla entry.a Bugzilla tracks ideas, Gerrit tracks code changes. Not sure it's optimal, but I find it more comfortable than dealing with patches to merge and test, mark obsolete and put comments without a scope in Bugzilla. I also think it makes it easier to review a contribution when we see it does not introduce regression before even we look at the code. And I also find it easy for a contributor to learn to take care about regression tests when pushing a change on Gerrit: if he broke something, a mail automatically warns the contributor. It tends to give more sense of responsibility and then to provide better quality in patches. SWTBot enabled Gerrit last year. Since then, project had 8 new contributors; for a total of 20 contributors in 5 years of existence. I'm not sure it is directly related, but I do feel Gerrit has been helpful to increase project activity, diversity and openness. My 2c. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
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 dschae...@qnx.com 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Three words: Fetch from Gerrit…. Can't beat that for downloading a change and trying it out. From: John Arthorne john_artho...@ca.ibm.commailto:john_artho...@ca.ibm.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Monday, 7 October, 2013 9:51 AM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit Doug Schaefer dschae...@qnx.commailto:dschae...@qnx.com 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
On 2013-10-07, at 7:03 AM, Thanh Ha thanh...@eclipse.org wrote: I've been meaning to write something up about this but haven't had the time. If you use the commandline there's a handy python script [1] that makes the Gerrit experience a little easier. The gist of it is that it's a bunch of shortcuts to working with the Gerrit workflow. For example git review -d change# will pull down a change and create a local branch for it automatically. No more copy/pasting the long commands that Gerrit provides. Maybe something similar can be integrated into Egit? Yeah, um, there is some tooling for that. It's called Mylyn Reviews. ;D 1. Open the Review editor for that change. 2. Scroll down to the last patch set. 3. Click Fetch. Glad to see so much discussion around this! I think the most important point was made by a couple of people -- it doesn't really hurt to at least enable it. There is a really important network effect here for contributors that I'd like to point out. People talk about there being a lot to learn to get up to speed on Gerrit -- that's true to some extent, but it's a one time cost and the EGit and Reviews tooling helps. The point is that once you know how to make and accept contributions to one project, it's the exact same process for every other project. As more and more projects move to Gerrit, this will become the expected way to contribute. I personally would be *much* more likely to contribute to a project that had Gerrit enabled -- and that was actually the impetus for my post…wanting to contribute something to a project that hadn't yet been enabled. (And no, I won't name names.. ;)) On Fri, Oct 4, 2013 at 12:00 PM, Ian Bull irb...@eclipsesource.com wrote: I really like the flow that Gerrit provides. Pushing commits is easier than creating patchs and uploading them. However, I find with Gerrit (or our use of Gerrit) is that the discussion is now spread across multiple mediums. Bugs / feature requests come in on bugzilla where some discussion happens. A change-set then appears are Gerrit where more discussion happens. Further requirements / ideas appear back on the bug and suddenly the change is updated. I find it difficult to follow the discussion. With bugzilla (or our use of it), all discussions (from conception, to requirements, to design, to implementation, to delivery) happen in one continuos thread. I'm not sure how the more experienced Gerrit users deal with this. Gerrit developers try to do most discussion on the change itself, and avoid using the mailing list or the bug tracker to discuss something. But we have a similar opinion that the fractured discussion is not useful. Right. For me, it's really the worst aspect of Gerrit. I find myself struggling to remember whether a discussion happened on a bug or on a review. It makes it even more interesting, because there isn't a one-to-one mapping between reviews and bugs as many people assume. There may even be cross-cutting concerns, so while there is a primary bug, we really need to be able to support more complex references. In general we need much better traciblity between defects and reviews -- that's something we're really interested in as an active dev topic. It might be interesting to think about having some sort of plugin in Gerrit that can grab comments from the related bug and include them interleaved by timestamp with Gerrit events, so the entire discussion is visible in one place on the Gerrit web UI. ___ Yes, this is something that would be really interesting to take a look at for Mylyn Reviews dashboard UI! (cc'ing Mylyn Reviews list for any follow-up on that, please exclude x-platform from any related follow-up.) Miles T. Parker | Tasktop Labs | Tasktop Technologies 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.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
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.me...@gmail.commailto:ed.me...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 2:34 AM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org 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=Communitycomponent=Gerritshort_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email: miles.par...@tasktop.commailto:miles.par...@tasktop.com 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.orgmailto: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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
On 10/04/2013 04:22 PM, 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. I can already imagine the various posts from Wayne on blogs/Twitter/mailing-list: Move to Gerrit by the end of 2013, or get your project archived. And then: Disable direct push to Git repo and get every change on Gerrit by the end of Spring, or get your project archived. And then: Get Hudson CI posting feedback on Git reviews, or get your project archived. Benevolent dictatorship at work ;) -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
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.me...@gmail.com mailto:ed.me...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 2:34 AM To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org 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=Communitycomponent=Gerritshort_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email:miles.par...@tasktop.com 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
the eTrice project is already running a HIPP with Gerrit trigger. It's just great! It significantly reduced the time I spend with reviews -Henrik Am 04.10.2013 16:22, schrieb Doug Schaefer: 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.me...@gmail.com mailto:ed.me...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 2:34 AM To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org 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=Communitycomponent=Gerritshort_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email: miles.par...@tasktop.com 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
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.me...@gmail.com mailto:ed.me...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 2:34 AM To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org 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=Communitycomponent=Gerritshort_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email:miles.par...@tasktop.com 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
In my defense, the push to Git had two major motivators: 1) CVS is no longer supported and has--as I understand it--several major open bugs that aren't being addressed 2) With the introduction of Git, something had to go; Webmaster does not have infinite resources. The push to Git had very real practical and pragmatic motivation. Further, CVS was deprecated for a full two years before we started compelling projects to move. With that precedent established, you have until at least 2015 to accept Gerrit :-) On a serious note, Eclipse projects are required to make reasonable effort to encourage and accept contributions. Adoption of Gerrit is one way of making this easy. The Eclipse Foundation has no plan to force Gerrit on any project. PMCs may have a different opinion. Wayne On 10/04/2013 10:30 AM, Mickael Istria wrote: On 10/04/2013 04:22 PM, 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. I can already imagine the various posts from Wayne on blogs/Twitter/mailing-list: "Move to Gerrit by the end of 2013, or get your project archived". And then: "Disable direct push to Git repo and get every change on Gerrit by the end of Spring, or get your project archived". And then: "Get Hudson CI posting feedback on Git reviews, or get your project archived". Benevolent dictatorship at work ;) -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
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.me...@gmail.com mailto:ed.me...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 2:34 AM To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org 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=Communitycomponent=Gerritshort_desc=Enable%20Gerrit%20for%20my%20project cheers, Miles Miles T. Parker | Tasktop Labs | Tasktop Technologies email:miles.par...@tasktop.com 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
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Yes. Patches attached to bugzilla are easier. -- Regards, Igor On 2013-10-04 12:25 PM, Mickael Istria wrote: On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
jetty generally finds this to be the case as well -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Oct 4, 2013 at 12:54 PM, Igor Fedorenko i...@ifedorenko.com wrote: Yes. Patches attached to bugzilla are easier. -- Regards, Igor On 2013-10-04 12:25 PM, Mickael Istria wrote: On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.**wordpress.comhttp://mickaelistria.wordpress.com - My Tweets http://twitter.com/**mickaelistria http://twitter.com/mickaelistria __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Though we enabled gerrit for p2, I must admit that I like patches on bugzilla easier. For the sake of understanding, could you please detail what do you harder with gerrit? -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Igor Fedorenko Sent: October-04-13 1:54 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit Yes. Patches attached to bugzilla are easier. -- Regards, Igor On 2013-10-04 12:25 PM, Mickael Istria wrote: On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Hi This seems backwatds. To my way of thinking Gerrit should be making GIT and Bugzilla better. If it tries to replace them it is sure to leave a lot of users disappointed and irritated. Therefore once the Gerrit ping-pong is complete, the Gerrit results should be transferred in their entirety to Bugzilla/GIT as if the action had happened there in the first place. Regards Ed Willink On 04.10.2013 15:38, Shawn Pearce wrote: On Fri, Oct 4, 2013 at 12:00 PM, Ian Bull irb...@eclipsesource.com wrote: I really like the flow that Gerrit provides. Pushing commits is easier than creating patchs and uploading them. However, I find with Gerrit (or our use of Gerrit) is that the discussion is now spread across multiple mediums. Bugs / feature requests come in on bugzilla where some discussion happens. A change-set then appears are Gerrit where more discussion happens. Further requirements / ideas appear back on the bug and suddenly the change is updated. I find it difficult to follow the discussion. With bugzilla (or our use of it), all discussions (from conception, to requirements, to design, to implementation, to delivery) happen in one continuos thread. I'm not sure how the more experienced Gerrit users deal with this. Gerrit developers try to do most discussion on the change itself, and avoid using the mailing list or the bug tracker to discuss something. But we have a similar opinion that the fractured discussion is not useful. It might be interesting to think about having some sort of plugin in Gerrit that can grab comments from the related bug and include them interleaved by timestamp with Gerrit events, so the entire discussion is visible in one place on the Gerrit web UI. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
On 10/04/2013 09:00 PM, Ian Bull wrote: I'm not sure how the more experienced Gerrit users deal with this. I don't consider myself as an expert, but I generally try to keep discussion related to use-case, test scenario and possible designs on the Bugzilla, and put discussions about code itself of Gerrit as it allows inline comments in contributions, versioning and comparison of patches, easy fetch, automatic CI check. When the discussion on Bugzilla has come to a point where it becomes possible to write code, I put a link to a Gerrit contrib on Bugzilla. Then most of the discussion happens on the Gerrit patch, and when it is done, it gets merged and then we can close the Bugzilla entry.a Bugzilla tracks ideas, Gerrit tracks code changes. Not sure it's optimal, but I find it more comfortable than dealing with patches to merge and test, mark obsolete and put comments without a scope in Bugzilla. I also think it makes it easier to review a contribution when we see it does not introduce regression before even we look at the code. And I also find it easy for a contributor to learn to take care about regression tests when pushing a change on Gerrit: if he broke something, a mail automatically warns the contributor. It tends to give more sense of responsibility and then to provide better quality in patches. SWTBot enabled Gerrit last year. Since then, project had 8 new contributors; for a total of 20 contributors in 5 years of existence. I'm not sure it is directly related, but I do feel Gerrit has been helpful to increase project activity, diversity and openness. My 2c. -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
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. And can't help wonder that these two statements aren't related in some way: m2e has no plans to accept gerrit contributions We have extremely low level of contributions. On 2013-10-04 1:54 PM, Igor Fedorenko i...@ifedorenko.com wrote: Yes. Patches attached to bugzilla are easier. -- Regards, Igor On 2013-10-04 12:25 PM, Mickael Istria wrote: On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
Yes, that generally how we work too. We're big users of Gerrit internally here on Momentics. That's generally how things go. Discussions happen in our bug system (JIRA), but only comments on the code happen in Gerrit. In all the bugzilla's I've looked at over the years, there actually weren't that many detailed code discussions there anyway. Gerrit lets you attach comments right to the lines. Bugzilla has never claimed to be a code review tool. BTW, great to hear that about SWTbot. You can't help but think making contribution and review easier is healthy for a project. Doug. From: Mickael Istria mist...@redhat.commailto:mist...@redhat.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Friday, 4 October, 2013 5:24 PM To: cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit On 10/04/2013 09:00 PM, Ian Bull wrote: I'm not sure how the more experienced Gerrit users deal with this. I don't consider myself as an expert, but I generally try to keep discussion related to use-case, test scenario and possible designs on the Bugzilla, and put discussions about code itself of Gerrit as it allows inline comments in contributions, versioning and comparison of patches, easy fetch, automatic CI check. When the discussion on Bugzilla has come to a point where it becomes possible to write code, I put a link to a Gerrit contrib on Bugzilla. Then most of the discussion happens on the Gerrit patch, and when it is done, it gets merged and then we can close the Bugzilla entry.a Bugzilla tracks ideas, Gerrit tracks code changes. Not sure it's optimal, but I find it more comfortable than dealing with patches to merge and test, mark obsolete and put comments without a scope in Bugzilla. I also think it makes it easier to review a contribution when we see it does not introduce regression before even we look at the code. And I also find it easy for a contributor to learn to take care about regression tests when pushing a change on Gerrit: if he broke something, a mail automatically warns the contributor. It tends to give more sense of responsibility and then to provide better quality in patches. SWTBot enabled Gerrit last year. Since then, project had 8 new contributors; for a total of 20 contributors in 5 years of existence. I'm not sure it is directly related, but I do feel Gerrit has been helpful to increase project activity, diversity and openness. My 2c. -- Mickael Istria Eclipse developer at JBoss, by Red Hathttp://www.jboss.org/tools My bloghttp://mickaelistria.wordpress.com - My Tweetshttp://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
