Steering Committee issues for next week

[Ray Cromwell]

Google I/O is upon us as we'd like to have something concrete to say
by I/O even if the actual process (e.g. new commit workflow) hasn't
been opened by then. To that end, there are a number of practical
things we need to discuss.


1. GIT has already been decided on. We need to decide on a hosting
provider. Options are Google Projects or Github. If there is a third
provider someone wants to propose, the group can consider that as
well.

2. Source Tree Management. Bhaskar (Google) has a straw proposal
(https://docs.google.com/a/google.com/document/d/
1gRJnBd9TOhRg6eMKhEVIX3cfG_qaz8fs1aqbLjR_MCk/edit) There are two goals
(Google) is interested in. First, allowing trunk to not be gated by
internal Google projects. Second, ensuring a 'high quality' release
branches that internal Google projects can depend on. There are many
ways this could happen, I'm open to counter proposals. Part of
Bhaskar's document is influenced by the GCC process already used by
Google, part of the nomenclature comes from Chrome's "Dev-Beta-Stable"
6-week process. We are also open to vendor branches living in the same
repo, so if Red Hat or Vaadin want to have their own branches, that is
fine. This is often done for tool integration (e.g. GWT Designer used
to have a hacked/forked GWT embedded in it) Overall, we want to get
Google out of the bottleneck of blocking commits because of invisible
confidential apps being broken that you can't see, but still maintain
a high quality stable codebase.

3. Build system. Ant? Maven? Ant+Ivy? Gyp?

4. Testing. Part of the problem of Google's current predicament is
that GWT's test suite isn't sufficient to cover all the cases that
break our internal apps. I propose that Reviewers demand reasonable
tests be submitted with patches (100% coverage I think is
unreasonable, use good judgement)

5. Code-style. Keep GWT's current code-style/checkstyle

6. Buildbot. We need continuous builds. GWT has somewhat complex
requirements due to cross browser testing. Any ideas on vendors to use
would be helpful.

Let the games begin. :)

-Ray

[Daniel Kurka]

On Jun 11, 7:11 pm, Ray Cromwell <cromwell...@google.com> wrote:
> Google I/O is upon us as we'd like to have something concrete to say
> by I/O even if the actual process (e.g. new commit workflow) hasn't
> been opened by then. To that end, there are a number of practical
> things we need to discuss.
>


> 1. GIT has already been decided on. We need to decide on a hosting
> provider. Options are Google Projects or Github. If there is a third
> provider someone wants to propose, the group can consider that as
> well.

If we want to use the google code issue tracker we should be using the
git repos on google code as well, since its going to be much easier to
link issues with code.
What we do with mgwt: We have a post commit script running that
mirrors changes to github after a push to google code. May this is the
way to go...

>
> 2. Source Tree Management. Bhaskar (Google) has a straw proposal
> (https://docs.google.com/a/google.com/document/d/
> 1gRJnBd9TOhRg6eMKhEVIX3cfG_qaz8fs1aqbLjR_MCk/edit) There are two goals
> (Google) is interested in. First, allowing trunk to not be gated by
> internal Google projects. Second, ensuring a 'high quality' release
> branches that internal Google projects can depend on. There are many
> ways this could happen, I'm open to counter proposals. Part of
> Bhaskar's document is influenced by the GCC process already used by
> Google, part of the nomenclature comes from Chrome's "Dev-Beta-Stable"
> 6-week process. We are also open to vendor branches living in the same
> repo, so if Red Hat or Vaadin want to have their own branches, that is
> fine. This is often done for tool integration (e.g. GWT Designer used
> to have a hacked/forked GWT embedded in it) Overall, we want to get
> Google out of the bottleneck of blocking commits because of invisible
> confidential apps being broken that you can't see, but still maintain
> a high quality stable codebase.
>
> 3. Build system. Ant? Maven? Ant+Ivy? Gyp?

@Thomas: What is the state of the current maven build?

[Thomas Broyer]

On Monday, June 11, 2012 7:11:16 PM UTC+2, Ray Cromwell wrote:

Google I/O is upon us as we'd like to have something concrete to say
by I/O even if the actual process (e.g. new commit workflow) hasn't
been opened by then. To that end, there are a number of practical
things we need to discuss.


1. GIT has already been decided on. We need to decide on a hosting
provider. Options are Google Projects or Github. If there is a third
provider someone wants to propose, the group can consider that as
well.

Same as Daniel. I'd rather keep Google Code Hosting, at least as a first step.

I'm open to moving elsewhere (GitHub's pull requests are great! I must say haven't yet understood the contribution workflow at Google Code, but if we're going to keep a separate code review tool then we only need a Git repo to push changes in).

Ray, you said (I believe it was on G+) that you'd like to move to Gerrit. Gerrit having its own Git repo (that must remain the canonical one), that means any other Git repo would only be a mirror (Gerrit handles mirroring fine, so it's not an issue; Gerrit itself is hosted in Gerrit and mirrored to Google Code; Android, OpenStack and CloudFoundry also use Gerrit with mirrors on GitHub), so it doesn't really matter where the repo is. What would matter then is where Gerrit is hosted.

Also, using Gerrit for code reviews probably means GitHub Pull Requests shouldn't be used. For instance, OpenStack uses a Web Hook to automatically close any

Would it be possible that Google set up a Gerrit instance at googlesource.com like it did for Android and for Gerrit itself? Otherwise, unless someone wants to host a Gerrit instance, we'd be better off continuing with Rietveld (and host wherever we want, Google Code would be just fine) or moving to GitHub and its Pull Requests. Or anyone has another idea?

Also note that moving to GitHub (or anywhere else) would probably mean moving the issues and wiki pages too. Not impossible, but some additional work.

Finally, Gerrit imposes a "by commit" review, and rebasing and amending commits until they're OK. This is quite different from, say, a GitHub Pull Request, where you review a whole set of commits at once.

I'm OK with Gerrit's approach (it favors a "clean history"), and I prefer when people amend their commits in GitHub Pull Requests rather than add "integrate feedback" and other "fix X or Y" commits, but it might annoy others.

So, to sum up, here are the current options, in personal preference order:

 1. have Google setup a Gerrit instance at googlesource.com, mirroring to Google Code (issues and wiki pages are kept unchanged)

 2. ex-æquo:

   2.a. continue using gwt-code-review.appspot.com, with the Git repo at Google Code (issues and wiki pages are kept unchanged)

   2.b. move repo to GitHub, use Pull Requests for code reviews, keep issues and wiki pages at Google Code Hosting.

 3. move to GitHub, move issues and wiki pages too (todo: investigate feasibility; would require more work)

 

2. Source Tree Management. Bhaskar (Google) has a straw proposal
(https://docs.google.com/a/google.com/document/d/
1gRJnBd9TOhRg6eMKhEVIX3cfG_qaz8fs1aqbLjR_MCk/edit) There are two goals
(Google) is interested in. First, allowing trunk to not be gated by
internal Google projects. Second, ensuring a 'high quality' release
branches that internal Google projects can depend on. There are many
ways this could happen, I'm open to counter proposals. Part of
Bhaskar's document is influenced by the GCC process already used by
Google, part of the nomenclature comes from Chrome's "Dev-Beta-Stable"
6-week process. We are also open to vendor branches living in the same
repo, so if Red Hat or Vaadin want to have their own branches, that is
fine. This is often done for tool integration (e.g. GWT Designer used
to have a hacked/forked GWT embedded in it) Overall, we want to get
Google out of the bottleneck of blocking commits because of invisible
confidential apps being broken that you can't see, but still maintain
a high quality stable codebase.

Who will be responsible for testing things in the "dev" before they're moved to "beta"?

Who intends to take advantage of that "beta" branch besides Google?

This is the major pain-point AFAICT. If Google is the only day-to-day user of "beta", then they'll likely be the only one to decide what to cherry-pick, which makes that "beta" branch a "vendor" branch in practice.

Also, how is Google intending to sync with their internal build system? Using MOE (or moe-java)?

If they can easily revert changes on their side pending an upstream fix, or changes downstream to accommodate for the change, without totally blocking their sync'ing process, then a "beta" line wouldn't be needed (if Google would be the only day-to-day user of that code line!).

The more information we have, the easier we can make a decision.

 

3. Build system. Ant? Maven? Ant+Ivy? Gyp?

An aside question is: are we going to modularize the build. It seems like Google would like it to happen. I do too.

If we modularize, then I'm afraid Ant is not an option. It's already quite complicated to maintain the current build, and it won't scale with more modules and more complex dependencies.

Ant+Ivy might be a solution but I don't know it.

I'm used to Maven, and there aren't many things done today that couldn't be done with Maven (including the recent Elemental code generation).

Gyp seems to be tailored for C/C++ builds rather than Java builds (even though they seem to be possible quite easily), and I doubt anyone here actually really knows it.

FYI, besides compilation, and putting apart things very specific to the way things are currently built, the build currently uses (AFAICT):

 - a custom JavaDoc doclet, to include examples

 - custom Ant task to get the current SVN revision, to put it in the About.java, and about.html in the SDK (other custom tasks are not really useful outside Ant)

 - custom Checkstyle checks

 - Elemental runs a Python script to generate Java code from IDL, the script needs GCC (or actually any compatible preprocessor) to preprocess the IDL files; this is why Elemental is not currently built by default when you do an "ant dist".

Nothing seems to be an issue in a Maven build: "there's a plugin for that".

There are also a few things run manually, committed to the SVN, and then only picked up by the build:

 - protocol buffer protoc (for DevMode's RemoteUI, for integration within Eclipse)

 - JNI (to use IE on Windows for the automatic update check at DevMode/Compiler startup, to use the platforms' proxy configuration)

 - DevMode plugins

Basically, what we need is a way to manage dependencies between modules, all of Ivy, Gyp and Maven (and Gradle, Buildr, etc.) do it.

I'm not opposed to Gyp or Ivy, but would prefer Maven. I could go with Gradle if others think it's better.

BTW, if going Maven, I'd like to pull the gwt-maven-plugin within GWT as an "official" plugin, and as a rewrite from scratch (too much legacy and (imo) badly designed things in the current plugin if you ask me)

 

4. Testing. Part of the problem of Google's current predicament is
that GWT's test suite isn't sufficient to cover all the cases that
break our internal apps. I propose that Reviewers  demand reasonable
tests be submitted with patches (100% coverage I think is
unreasonable, use good judgement)

+1

“80% and no less!” ;-)

http://googletesting.blogspot.fr/2010/07/code-coverage-goal-80-and-no-less.html

 

5. Code-style. Keep GWT's current code-style/checkstyle

6. Buildbot. We need continuous builds. GWT has somewhat complex
requirements due to cross browser testing. Any ideas on vendors to use
would be helpful.

Maybe Google could give us some numbers? How much time does it take to run, say, the user tests? Do you run them in DevMode + prodmode, in HtmlUnit and real browsers, and with and without EMMA at each commit within gwt-dev or gwt-user? Which platforms/browsers do you run tests in?

I ask that because I already suggested CloudBees and SauceLabs, but I have no idea how much it could cost, and we would have to find people to pay for it if needed :-)

And if people here already have such infras, they'll likely want those numbers before proposing giving resources to the GWT project.

[Thomas Broyer]

On Tuesday, June 12, 2012 1:25:16 PM UTC+2, Daniel Kurka wrote:

> 3. Build system. Ant? Maven? Ant+Ivy? Gyp? 

@Thomas: What is the state of the current maven build?

Far from done actually, because more than a "maven build" I was thinking about modularizing it (gwt-dev only for now, not gwt-user).

Attached is what the dependency graph could look like. I only modularized gwt-dev, and extracted a gwt-shared out of gwt-user and gwt-servlet, and similarly for requestfactory. The main goal was extracting a gwt-dev-ext with the generator and linker API, and a standalone gwt-compiler, and overall avoid duplicating classes within artifacts. I specifically didn't split gwt-user (besides gwt-shared), and this is why it depends on requestfactory-shared (rather than introducing a requestfactory-gwt for instance).

Also, I haven't updated the graph with Elemental, as I think it'll change (it would be great to extract element.json and use it for AutoBeans, for instance; even better would be to switch sourcemap and closure-compiler to it too).

In the graph, what I called "custom 3rd-party libs" are things that have been extracted from other projects (sourcemap from the Closure Compiler, and streamhtmlparser from JSilver) or otherwise not distributed as Maven artifacts (Closure Compiler).

As for the file layout, I'd go with (this is just a proposal):

- build-tools

  - gwt-customchecks

- common

- dev

  - gwt-dev-ext

  - gwt-compiler

  - gwt-dev

  - gwt-codeserver

- user

 - gwt-user

 - gwt-shared

 - gwt-servlet

- requestfactory

  - requestfactory-client

  - requestfactory-shared

  - requestfactory-server

  - requestfactory-apt

- dist # SDK package

  - gwt-dev

  - gwt-servlet

  - gwt-user

  - gwt-servlet-deps

Note that "dist" would not be a "module" of the parent project. The idea is that a "mvn install" (or whatever) at the root level would build everything but the distributable SDK, similar to an "ant dist-dev" today. The equivalent to "ant dist" would be "mvn install && cd dist && mvn install".

[Stephen Haberman]

> So, to sum up, here are the current options, in personal preference
> order:

I agree with Thomas's preferences.

A Google-hosted Gerrit would be even more awesome if we could have some
sort of build farm (Google- or whoever-based) watching Gerrit, running
tests, and voting +1/-1.

I've never had the opportunity to work with this sort of setup, so don't
know a lot of the operational details, but given GWT's large test suite
that needs to be run in multiple browsers, and the non-trivialness of
running them all the time locally, I would really enjoy the extra
insurance of having commits pre-vetted to pass the tests.

- Stephen

[Mike Brock]

Some comments inline. Sorry for the brevity. But I've only got about 15 minutes before I lose my signal. 

On Jun 16, 2012, at 7:45 AM, Thomas Broyer wrote:

On Monday, June 11, 2012 7:11:16 PM UTC+2, Ray Cromwell wrote:

Google I/O is upon us as we'd like to have something concrete to say
by I/O even if the actual process (e.g. new commit workflow) hasn't
been opened by then. To that end, there are a number of practical
things we need to discuss.


1. GIT has already been decided on. We need to decide on a hosting
provider. Options are Google Projects or Github. If there is a third
provider someone wants to propose, the group can consider that as
well.

Same as Daniel. I'd rather keep Google Code Hosting, at least as a first step.

I'm open to moving elsewhere (GitHub's pull requests are great! I must say haven't yet understood the contribution workflow at Google Code, but if we're going to keep a separate code review tool then we only need a Git repo to push changes in).

I would like to strongly suggest using Github. If we're going to Git, the act of moving to Github is practically friction-free. There's also nothing particularly complex about co-hosting it, either. 

The reason I think hosting at Github is worth pushing for, is it is there is just something about Github that makes people want to contribute. It has collaboration at its core. The way the pull request workflow works cannot be understated. It is an absolutely fantastic way to manage community patches. It's easy to make them. It's easy to review them. It's easy to accept them. And, in my opinion, the less friction there is within the tiers of development, the more time we'll have to focus on moving GWT forward and encouraging others to contribute to that.

Git repositories can be cloned and synced with absolute ease. So whether or not the master branch lives at Github or Google Code won't affect the complexity of setting up Gerrit or any automated testing. Indeed, our public repositories. Indeed, we do this very thing at Red Hat. 

Finally, I think the move to Github is a way to make a "splash" out of this effort. There already is a Google Code project, and moving from SVN to Git will be a very low visibility change. But if the GWT project shows up at Github, people are really going to notice. 

The Errai project would definitely be interest in testing against the beta branch, and staying ahead of the curve on GWT. So you can count us in. 

Also, how is Google intending to sync with their internal build system? Using MOE (or moe-java)?

If they can easily revert changes on their side pending an upstream fix, or changes downstream to accommodate for the change, without totally blocking their sync'ing process, then a "beta" line wouldn't be needed (if Google would be the only day-to-day user of that code line!).

The more information we have, the easier we can make a decision.

 

3. Build system. Ant? Maven? Ant+Ivy? Gyp?

An aside question is: are we going to modularize the build. It seems like Google would like it to happen. I do too.

If we modularize, then I'm afraid Ant is not an option. It's already quite complicated to maintain the current build, and it won't scale with more modules and more complex dependencies.

Ant+Ivy might be a solution but I don't know it.

I'm used to Maven, and there aren't many things done today that couldn't be done with Maven (including the recent Elemental code generation).

Gyp seems to be tailored for C/C++ builds rather than Java builds (even though they seem to be possible quite easily), and I doubt anyone here actually really knows it.

FYI, besides compilation, and putting apart things very specific to the way things are currently built, the build currently uses (AFAICT):

 - a custom JavaDoc doclet, to include examples

 - custom Ant task to get the current SVN revision, to put it in the About.java, and about.html in the SDK (other custom tasks are not really useful outside Ant)

 - custom Checkstyle checks

 - Elemental runs a Python script to generate Java code from IDL, the script needs GCC (or actually any compatible preprocessor) to preprocess the IDL files; this is why Elemental is not currently built by default when you do an "ant dist".

Nothing seems to be an issue in a Maven build: "there's a plugin for that".

There are also a few things run manually, committed to the SVN, and then only picked up by the build:

 - protocol buffer protoc (for DevMode's RemoteUI, for integration within Eclipse)

 - JNI (to use IE on Windows for the automatic update check at DevMode/Compiler startup, to use the platforms' proxy configuration)

 - DevMode plugins

Basically, what we need is a way to manage dependencies between modules, all of Ivy, Gyp and Maven (and Gradle, Buildr, etc.) do it.

I'm not opposed to Gyp or Ivy, but would prefer Maven. I could go with Gradle if others think it's better.

Gradle is an interesting choice, and can give us a lot of flexibility, up to and including easy outward support with Maven. I think Maven is a good default choice, but I'd certainly be interested in exploring Gradle more fully.

BTW, if going Maven, I'd like to pull the gwt-maven-plugin within GWT as an "official" plugin, and as a rewrite from scratch (too much legacy and (imo) badly designed things in the current plugin if you ask me)

 

4. Testing. Part of the problem of Google's current predicament is
that GWT's test suite isn't sufficient to cover all the cases that
break our internal apps. I propose that Reviewers  demand reasonable
tests be submitted with patches (100% coverage I think is
unreasonable, use good judgement)

+1

 Errai's testsuite certainly flexes GWT's code generation APIs. I'd be happy to setup our Jenkins servers to do smoke testing against the master dev branch of GWT and publishing those reports for everyone in real-time. If we can get enough projects doing this, we'd go a long way to getting a really good smoke test suite with quick feedback.

“80% and no less!” ;-)

http://googletesting.blogspot.fr/2010/07/code-coverage-goal-80-and-no-less.html

 

5. Code-style. Keep GWT's current code-style/checkstyle

Yes.

6. Buildbot. We need continuous builds. GWT has somewhat complex
requirements due to cross browser testing. Any ideas on vendors to use
would be helpful.

I can look at getting us some reasonable provisioning on Red Hat's OpenShift infrastructure to run Jenkins, if people are interested.

[Daniel Kurka]

Am 16.06.2012 um 20:34 schrieb Mike Brock:

Some comments inline. Sorry for the brevity. But I've only got about 15 minutes before I lose my signal. 

On Jun 16, 2012, at 7:45 AM, Thomas Broyer wrote:

On Monday, June 11, 2012 7:11:16 PM UTC+2, Ray Cromwell wrote:

Google I/O is upon us as we'd like to have something concrete to say
by I/O even if the actual process (e.g. new commit workflow) hasn't
been opened by then. To that end, there are a number of practical
things we need to discuss.


1. GIT has already been decided on. We need to decide on a hosting
provider. Options are Google Projects or Github. If there is a third
provider someone wants to propose, the group can consider that as
well.

Same as Daniel. I'd rather keep Google Code Hosting, at least as a first step.

I'm open to moving elsewhere (GitHub's pull requests are great! I must say haven't yet understood the contribution workflow at Google Code, but if we're going to keep a separate code review tool then we only need a Git repo to push changes in).

I would like to strongly suggest using Github. If we're going to Git, the act of moving to Github is practically friction-free. There's also nothing particularly complex about co-hosting it, either. 

The reason I think hosting at Github is worth pushing for, is it is there is just something about Github that makes people want to contribute. It has collaboration at its core. The way the pull request workflow works cannot be understated. It is an absolutely fantastic way to manage community patches. It's easy to make them. It's easy to review them. It's easy to accept them. And, in my opinion, the less friction there is within the tiers of development, the more time we'll have to focus on moving GWT forward and encouraging others to contribute to that.

Git repositories can be cloned and synced with absolute ease. So whether or not the master branch lives at Github or Google Code won't affect the complexity of setting up Gerrit or any automated testing. Indeed, our public repositories. Indeed, we do this very thing at Red Hat. 

Finally, I think the move to Github is a way to make a "splash" out of this effort. There already is a Google Code project, and moving from SVN to Git will be a very low visibility change. But if the GWT project shows up at Github, people are really going to notice. 

if we move to github we need to take the issue tracker and the wiki with us. This would be a lot of work. This is why I suggested staying on google code in the first place.

[Mike Brock]

On Jun 16, 2012, at 2:46 PM, Daniel Kurka wrote:

Am 16.06.2012 um 20:34 schrieb Mike Brock:

Some comments inline. Sorry for the brevity. But I've only got about 15 minutes before I lose my signal. 

On Jun 16, 2012, at 7:45 AM, Thomas Broyer wrote:

On Monday, June 11, 2012 7:11:16 PM UTC+2, Ray Cromwell wrote:

Google I/O is upon us as we'd like to have something concrete to say
by I/O even if the actual process (e.g. new commit workflow) hasn't
been opened by then. To that end, there are a number of practical
things we need to discuss.


1. GIT has already been decided on. We need to decide on a hosting
provider. Options are Google Projects or Github. If there is a third
provider someone wants to propose, the group can consider that as
well.

Same as Daniel. I'd rather keep Google Code Hosting, at least as a first step.

I'm open to moving elsewhere (GitHub's pull requests are great! I must say haven't yet understood the contribution workflow at Google Code, but if we're going to keep a separate code review tool then we only need a Git repo to push changes in).

I would like to strongly suggest using Github. If we're going to Git, the act of moving to Github is practically friction-free. There's also nothing particularly complex about co-hosting it, either. 

The reason I think hosting at Github is worth pushing for, is it is there is just something about Github that makes people want to contribute. It has collaboration at its core. The way the pull request workflow works cannot be understated. It is an absolutely fantastic way to manage community patches. It's easy to make them. It's easy to review them. It's easy to accept them. And, in my opinion, the less friction there is within the tiers of development, the more time we'll have to focus on moving GWT forward and encouraging others to contribute to that.

Git repositories can be cloned and synced with absolute ease. So whether or not the master branch lives at Github or Google Code won't affect the complexity of setting up Gerrit or any automated testing. Indeed, our public repositories. Indeed, we do this very thing at Red Hat. 

Finally, I think the move to Github is a way to make a "splash" out of this effort. There already is a Google Code project, and moving from SVN to Git will be a very low visibility change. But if the GWT project shows up at Github, people are really going to notice. 

if we move to github we need to take the issue tracker and the wiki with us. This would be a lot of work. This is why I suggested staying on google code in the first place.

Well, we're on Github but we *don't* use the Github issue tracker. We use JIRA hosted on jboss.org infrastructure. In that sense, we're only using it for source management.  =)

[Thomas Broyer]

We set it up at work and I must say it works really well.

But you don't need Gerrit to have pre-tested commits.
As an example, BuildHive does it for GitHub Pull Requests, and you can
even push to a special Git repo which will trigger a build and push
back to GitHub (or whatever/wherever your Git repo is) if the build is
green.
See http://blog.cloudbees.com/2012/05/announcing-buildhive.html and
http://blog.cloudbees.com/2012/06/push-changes-to-buildhive-and-never-run.html
(this is a Jenkins Enterprise plugin
http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-features-validated-merge-plugin.cb,
you only get it in BuildHive –too limited for us– or the "Premium"
plan of DEV@Cloud FOSS Free http://www.cloudbees.com/foss/foss-dev.cb)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Stephen Haberman]

> But you don't need Gerrit to have pre-tested commits.

True, that's for correcting me on this.

I generally agree with Mike's point that moving to GitHub is a "crap,
they're really serious about this open source effort" sort of move.

I'll withdraw my vote for Gerrit and just say really I'm asking/voting
for pre-tested commits. How/where we get those I'm fairly ambivalent
about.

Thanks for the buildhive links, Thomas, I'll read in to it.

- Stephen

[Bhaskar Janakiraman]

Lots of email messages for a weekend, I'm surprised!

I'm not officially on the steering committee, but a brief comment -  if we stick with gerrit and code.google.com, we can tap on Google (for example, the people in the open source office here who help administer code.google) for help and on-going support. We (as in Google engineers) also know how to do this, and can set it up without any outside help.

The main reason to move to github would be if we wanted to use the 'pull request' workflow. Otherwise, we could just have it code.google.com and mirror it in github.  So the question is whether this is the workflow we want for GWT, or we prefer a gerrit workflow? 

Bhaskar

[Mike Brock]

I think the pull request workflow is very, very compelling as someone who uses it. =)

Mike.

[Christian Goudreau]

Pull requests are really awesome!

And I've used Rietveld with git and it can do branch comparison like Github does without any problem!

We're heavily using Github here too and I've been using google code for a while now and it's really easy to just clone the google code git repository once it's done without having to move the "official" repository.

When is our next meeting by the way? I though it was today :D

--

Christian Goudreau | CEO - Président

M: 1.877.635.1585 | S: christian.goudreau

ArcBees | Blog | Facebook | LinkedIn

[Ray Cromwell]

Tomorrow at 9am. Someone had a scheduling conflict last week so we
agreed to do tuesday.

-Ray

[Bhaskar Janakiraman]

On Mon, Jun 18, 2012 at 11:12 AM, Christian Goudreau <quee...@arcbees.com> wrote:

Pull requests are really awesome!

I haven't used github, but from what I know, this is mainly for non-maintainers to submit a request to the maintainers, right?  Most of us are committers, but given that this is a new project, I expect we'll want reviews from each other (probably a +2) before things get checked in, even on the dev line. I'm not sure how the pull request fits into that model. 

 

And I've used Rietveld with git and it can do branch comparison like Github does without any problem!

Personally, I find gerrit a much better review system than Rietveld. Perhaps we can teach it to deal with pull requests somehow? 

Bhaskar

[Mike Brock]

On Jun 18, 2012, at 8:03 PM, Bhaskar Janakiraman wrote:

On Mon, Jun 18, 2012 at 11:12 AM, Christian Goudreau <quee...@arcbees.com> wrote:

Pull requests are really awesome!

I haven't used github, but from what I know, this is mainly for non-maintainers to submit a request to the maintainers, right?  Most of us are committers, but given that this is a new project, I expect we'll want reviews from each other (probably a +2) before things get checked in, even on the dev line. I'm not sure how the pull request fits into that model. 

Yes. But I think if we want to use something like Gerrit, the master branch at Github would merely be a staging branch, for which we could then have Gerrit pull from. And only after the commits have made it through Gerrit would you end up with those commits in the "blessed" branch. The nice thing about Git, is achieving these sorts of workflows is very easy and turn-key.

[Ray Cromwell]

Stackoverflow has a number of interesting discussions on Gerrit +
GitHub, and Gerrit+GitHub+Jenkins.


Reminder everyone: Steering Meeting Tuesday @ 9am PDT, on the same
dialup number and conference ID as last time.

-Ray

[Thomas Broyer]

On Tue, Jun 19, 2012 at 2:03 AM, Bhaskar Janakiraman
<bjanak...@google.com> wrote:
>
>
> On Mon, Jun 18, 2012 at 11:12 AM, Christian Goudreau <quee...@arcbees.com>
> wrote:
>>
>> Pull requests are really awesome!
>>
>
> I haven't used github, but from what I know, this is mainly for
> non-maintainers to submit a request to the maintainers, right?

Actually, no.
Pull requests can be used between branches within the same project (to
merge a feature branch to master for instance).
See http://scottchacon.com/2011/08/31/github-flow.html and
http://zachholman.com/talk/how-github-uses-github-to-build-github

For "internal contributions", this is not much different from Gerrit
actually: Gerrit stores your changes within the Git repo in special
refs (within refs/changes), and once you have a "+2"+Verified and hit
"publish and submit", it merges the branch within the target branch
(the one you passed after refs/for/ or, in more recent versions,
refs/draft/ or refs/publish/)

> Most of us
> are committers, but given that this is a new project, I expect we'll want
> reviews from each other (probably a +2) before things get checked in, even
> on the dev line. I'm not sure how the pull request fits into that model.

Using both Gerrit and GitHub Pull Requests, I'll try to summarize the
differences:
• With Gerrit you "push for review" to a special ref (e.g. "git push
origin featureX:refs/publish/master" to push feature branch "featureX"
for review, to be eventually merged to refs/heads/master), while with
GitHub you push your feature branch, and then create a Pull Request to
have it merged.
• Gerrit has formal scores on reviews [1], and you cannot "submit"
(merge) a change until you have the configured score (by default you
need a +1 Verified and a +2 Code Review). GitHub is more like
Rietveld, where everything is just a comment. Contrary to Rietveld, it
doesn't even have the "LGTM" special bit (that colors the comment in
green in Rietveld).
• Gerrit makes a review per commit. You can push several commits at
once and you'll then have dependencies between changes, but you'll
have one review per commit. You can set a "label" to a set of commits
but it's only there to ease searching for them (i.e. listing all
reviews for a given label, which in general means listing all commits
of a given "feature branch"). In GitHub, you review a whole branch at
once; you can see each commit separately or see the whole diff between
the feature branch requested to be merged/pulled and the target
branch.
• Just like Rietveld, Gerrit keeps track of the different "patch
sets", and allows you to diff between them (you need to setup a hook
on your local repo that adds a Change-ID line to your commit message,
Gerrit uses that Change-Id as the identifier for the review; to update
your review, you amend your commit and push it again. On GitHub, you
push new commits to your branch and they show up in the Pull Request
(with a special "comment" listing which were added when). You can also
"git push --force" and it'll replace the commits (for a cleaner
history; this is the workflow for the Linux Kernel AFAICT, except they
don't use GitHub ;-) )
• Gerrit integrates the CLA signing process.

Implications of these differences:
• Gerrit encourages a “clean history” by reviewing each commit
separately; with GitHub you can be tempted to only review the
"branch-level diff" and let borked commits pass in (e.g. one change
that should have been in the first commit has mistakenly been put in
the second commit). Gerrit however does not (not yet! ) give you the
"big picture" when you review several dependent commits (i.e. a
feature branch).
• Gerrit has a much more formal review process than GitHub (Gerrit
can go even farther actually: you can, for instance, prevent users
from pushing directly to refs/heads/* and force them to go through
code reviews, this is the proposed configuration for a "developer"
role: http://gerrit.atolcd.priv/Documentation/access-control.html#_examples_of_typical_roles_in_a_project)
This has of course both advantages and drawbacks.
• GitHub makes it harder to work with pull requests where commits are
rebased/amended, because you cannot easily see the diffs between the
changes before and after they were amended, and as a result you cannot
easily see whether your comments have been addressed. So one workflow
(if you want a "clean history", which I generally prefer) would be to
first address the comments by appending commits, and then "rebase -i"
and "push --force" just before merging (with a new review pass to make
sure the commits are atomic).
• While GitHub makes it easier to work with "big changes" spread
across several dependent commits, it makes it harder to review changes
that touch many files, because everything's displayed on the same page
(which can even sometimes takes long to display). Gerrit on the other
hand displays each file separately (similar to Rietveld).
• Gerrit has a higher bar to entry, as you first have to setup a hook
(you also have to create an account and register your SSH public key,
this is no different from creating an account at GitHub, but has to be
done specifically for the Gerrit instance; I suppose Gerrit can easily
be taught to authenticate through GitHub, and then automatically
register your public SSH key from your GitHub account, but that would
require every contributor to have a GitHub account).

A last note, to make it clear to everyone: Gerrit is a Git server with
built-in code-review (and ACLs), it has to be your "canonical" Git
repo (you always push to Gerrit) and then it can replicate changes to
other servers (Google Code Hosting or GitHub for instance; OpenStack
and CloudFoundry replicate to GitHub, and we just set it up too with
our internal Gerrit server at work; and I suppose that's how Gerrit's
own code is replicated from Gerrit to Google Code Hosting).
If you replicate to GitHub for instance, you have to make sure you
never merge pull requests using the "merge" button (what we've done,
inspired by OpenStack's documentation of their own setup, is that only
our "atolcd-gerrit" user has "push" rights on the projects; we haven't
tried it yet but I suppose there wouldn't be a "merge" button on pull
requests for the developers –who only have "pull" rights–)

----

[1] For those people not knowing Gerrit, it comes with 2 scoring
categories by default: Verified and Code Review.

Verified ranges from -1 to +1, with the following meanings:
• +1: Verified
• 0: No score
• -1: Fails
That score is generally set by a CI server upon compiling the proposed
change. If you don't have a CI server that automatically verifies
reviews, the general idea is that a reviewer pulls the change locally
and manually verifies that it works.
BuildHive, for instance, automatically builds your GitHub Pull
Requests, but all it can do is then comment on it saying whether the
build succeeded or failed; this is a lot less formal that this
Verified score (which is not necessarily a bad thing; it's just…
different).

Code Review ranges from -2 to +2, with the following meanings:
• +2 Looks good to me, approved
• +1 Looks good to me, but someone else must approve
• 0 No score
• -1 I would prefer that you didn't submit this
• -2 Do not submit
This score is set by reviewers. Note that two +1s does not equate a +2
(that should be configurable through some prolog script though, if
that's what you want)

To avoid overflooding their CI server (I suppose), OpenStack added a
special category "Approved". The CI server will only build the review
if it has an Approved score of +1 (they're using a patched version of
the Gerrit Trigger Plugin for Jenkins)

----

>> And I've used Rietveld with git and it can do branch comparison like
>> Github does without any problem!
>
>
> Personally, I find gerrit a much better review system than Rietveld. Perhaps
> we can teach it to deal with pull requests somehow?

Gerrit needing Change-Ids within the commit message, I doubt it'd be possible.
OpenStack chose to setup a webhook that automatically closes pull
requests with a message telling the author to use their Gerrit
instance instead, with a link to their documentation for how to
contribute to the project. CloudFoundry seems to be doing the same.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Thomas Broyer]

Some real-world examples to illustrate my comments about Gerrit vs. GitHub:

On Tue, Jun 19, 2012 at 11:19 AM, Thomas Broyer <t.br...@gmail.com> wrote:
>
> • Gerrit makes a review per commit. You can push several commits at
> once and you'll then have dependencies between changes, but you'll
> have one review per commit. You can set a "label" to a set of commits
> but it's only there to ease searching for them (i.e. listing all
> reviews for a given label, which in general means listing all commits
> of a given "feature branch"). In GitHub, you review a whole branch at
> once; you can see each commit separately or see the whole diff between
> the feature branch requested to be merged/pulled and the target
> branch.

Compare, for example:
https://github.com/tbroyer/gwt-maven-archetypes/pull/13/commits
with:
https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:assignChanges,n,z
Note that in Gerrit, it's a search on a given "topic", which is just a
label, and changes (commits) are not "in order", you have to pick one
of them and follow the "Depends On" and "Needed By" links. You can
even have distinct features with the same topic (e.g.
https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:plugins,n,z
)
In GitHub however, this is a "feature branch", so you see the commits
in that branch that are not on the target branch (basically, the
result of a "git rev-list master..featureX")

>  • GitHub makes it harder to work with pull requests where commits are
> rebased/amended, because you cannot easily see the diffs between the
> changes before and after they were amended, and as a result you cannot
> easily see whether your comments have been addressed. So one workflow
> (if you want a "clean history", which I generally prefer) would be to
> first address the comments by appending commits, and then "rebase -i"
> and "push --force" just before merging (with a new review pass to make
> sure the commits are atomic).

Here's from a few minutes ago:
My original pull request had received a comment:
https://github.com/gwt-maven-plugin/gwt-maven-plugin/commit/fa5b762a3b0341f9178a3db023d426370319769f#src-main-java-org-codehaus-mojo-gwt-shell-runmojo-java-P10
I amended my commit to take the comment into account and "git push
--force"; the original commit and its associated comment has
completely disappeared from the pull request:
https://github.com/gwt-maven-plugin/gwt-maven-plugin/pull/37

Compare that to Gerrit (review picked at random; linking here directly
to a specific file, diffing between the first and third "versions" of
the commit):
https://gerrit-review.googlesource.com/#/c/36150/1..3/gerrit-gwtui/src/main/java/com/google/gerrit/client/auth/openid/OpenIdSsoPanel.java
or Rietveld:
http://gwt-code-reviews.appspot.com/1727807/diff2/15003:10003/user/src/com/google/gwt/editor/client/impl/SimpleViolation.java
In both cases, you can see on the left the comments that were made at
the time, and the diff between between two "versions" of the code
review.

Having a "diff between patchsets" helps in concentrating only on what
changed since the last time you reviewed the code, which comes in
really helpful when reviewing "big changes".
This, to me, is a really big plus for Gerrit over GitHub, and the
reason I put it first on my list.
(also, hit Ctrl+? while in Gerrit ;-) )

I had to go back to using ReviewBoard at work for one review (we're
only using Git and Gerrit for new projects, older projects are still
in SVN), and while it can show me those "diffs between patchsets", it
doesn't show the comments made on the previous patchset. So I can see
what changed since the last time I reviewed the code, but I cannot see
at the same time *why* it changed (which incidentally leads to hateful
tweets https://twitter.com/tbroyer/status/214648105205903360 ;-) )
With GitHub, unless I add commits rather than amend them, I cannot
even see what changed.

> • While GitHub makes it easier to work with "big changes" spread
> across several dependent commits, it makes it harder to review changes
> that touch many files, because everything's displayed on the same page
> (which can even sometimes takes long to display). Gerrit on the other
> hand displays each file separately (similar to Rietveld).

Compare, for example:
https://github.com/tbroyer/gwt-maven-archetypes/pull/9/files
or https://github.com/tbroyer/gwt-maven-archetypes/pull/13/files
(and these are not really "big changes")
with:
https://gerrit-review.googlesource.com/36091
or:
http://gwt-code-reviews.appspot.com/1380807/

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Bhaskar Janakiraman]

Can you do a side-by-side diff/review in github? Your example doesn't show that....

The formality of gerrit is quite useful. For example, we have a whole infrastructure built around automated commits based not test results for chromeos.

Bhaskar

[Thomas Broyer]

On Tue, Jun 19, 2012 at 5:33 PM, Bhaskar Janakiraman
<bjanak...@google.com> wrote:
> Can you do a side-by-side diff/review in github? Your example doesn't show
> that....

No, no side-by-side diffs at GitHub.

> The formality of gerrit is quite useful. For example, we have a whole
> infrastructure built around automated commits based not test results for
> chromeos.

I totally agree. And you can still configure Gerrit with relaxed rules
if you want less.
I tried to stay objective (at least in my first mail, a bit less in
the second one ;-) ).

[Mike Brock]

On an aside: what is the call-in info for the meeting? Can someone
email it to me off list (bro...@gmail.com)?

[Ray Cromwell]

Call in:

International direct: +1 617 224.4646
US Toll free: 1 866 457.4646
Participant passcode: 22319011 then #

[Daniel Kurka]

this is on list ray :)