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<mailto:mist...@redhat.com>> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Date: Friday, 4 October, 2013 5:24 PM 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 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
