Can we move the code to GitHub?

[Benjamin Possolo]

I am interested in helping "modernize" the gwtproject.org website/documentation and part of that effort would include moving the code to GitHub.

I think GitHub provides a certain amount of credibility that lacks with the current Gerrit system.

Moving to GitHub would encourage more people to contribute and get involved because they are familiar with the github UI and the process for submitting pull requests, performing code reviews, etc.

Not to mention, it is simply much more social and transparent.

It sounds like Gerrit has a feature that only allows patches from people that have signed contributor legal agreements.

I guess I don't really understand why this is necessary now that GWT has become fully open sourced and is no longer owned by Google.

However, if this is actually necessary, couldn't we simply use a git commit hook to enforce it?

AngularJS is on GitHub..doesn't make sense to me why Google Web Toolkit can't be.

[Thomas Broyer]

On Sunday, March 30, 2014 3:41:33 AM UTC+2, Benjamin Possolo wrote:

I am interested in helping "modernize" the gwtproject.org website/documentation and part of that effort would include moving the code to GitHub.

I think GitHub provides a certain amount of credibility that lacks with the current Gerrit system.

Do you imply that the same system that is used for Android and ChromiumOS lacks credibility? The same that's also used by Eclipse, OpenStack, Typo3, Qt, Wikimedia, etc. https://code.google.com/p/gerrit/wiki/ShowCases

 

Moving to GitHub would encourage more people to contribute and get involved because they are familiar with the github UI and the process for submitting pull requests, performing code reviews, etc.

I agree GitHub is more familiar to many than Gerrit, and that would probably ease contributions.

But, as far as I'm concerned, I wouldn't move to GitHub (at least for GWT proper).

The main reasons we chose Gerrit were:

* side-by-side diffs

* enforcing a clean history (this is particularly important as Google syncs their internal Perforce repo with the public Git repo, the history needs to be linear for them)

The website doesn't have those "clean history" constraints, but it'd be a bit strange to use another system to review changes for the website than changes to GWT proper (note that I'm not strongly against it)

I believe you can find some discussions on the subject in the archives of https://groups.google.com/d/forum/gwt-steering

At GitHub, to maintain a clean history means that you either ask every contributor to rebase and squash their branches before you can merge them, and/or you rebase and squash them yourself when merging, but it at least means being very careful when clicking the "merge" button (so careful that you'd probably want to disable it –that's not possible– and force every commiter to merge manually with --ff-only or --squash).

We're starting seeing integrations between Gerrit and GitHub (http://gerrithub.io/), so who knows, maybe one day that plugin will be available on gwt-reviews so contributors will be able to submit changes as GitHub Pull Requests rather than pushing them to Gerrit.

In the mean time, I believe what we need is better documentation. Our "making GWT better" web page is really light. Patches welcome.

 

Not to mention, it is simply much more social and transparent.

!?

I could understand the "more social" argument (although I don't think it's a compelling one), but "more transparent"?

 

It sounds like Gerrit has a feature that only allows patches from people that have signed contributor legal agreements.

I guess I don't really understand why this is necessary now that GWT has become fully open sourced and is no longer owned by Google.

Required reading: http://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ and http://www.clahub.com/pages/why_cla

Ideally, the GWT Project would be a legal organization so you'd sign a CLA with the GWT Project. But it's not, so you still sign an agreement with Google.

 

However, if this is actually necessary, couldn't we simply use a git commit hook to enforce it?

Yes, there are things like CLAHub; but you need to train all committers to not look at patches until the CLA has been signed, it's not enforced.

Similarly, GitHub hooks with the PR status API can inform you of the build status of a pull request, but nothing prevents you from merging it. On the other hand, merging a change that fails to build in Gerrit needs special permissions (even though we don't do a full build, so in practice a change can still break the build without failing the pre-check)

 

AngularJS is on GitHub..doesn't make sense to me why Google Web Toolkit can't be.

Well, it is (https://github.com/gwtproject) but only as a mirror (to make forks easier), and not for all projects (it's probably just a matter of asking GitHub to mirror the missing projects). The issue tracker is still at code.google.com and contributions go through Gerrit.

Note: CloudFoundry tried Gerrit but moved to GitHub: http://redmonk.com/sogrady/2013/02/26/forking-permissive-licenses/#comment-813480084 I'd be interested in knowing the reasons for the change.

[Colin Alworth]

Only note to add here is that the AngularJS project does require a CLA also (see https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#cla) - it looks like they either have a bot which complains about missing CLAs on file (and so some associated between username and real name), or a very diligent user with a form that gets copy/pasted a lot. But, as Thomas noted, this can't stop a developer from accidently merging code which the contributor may not have the rights to merge.

Okay, one more though: Remember the mess between Google and Oracle over Android emulating the JRE, specifically the part about possibly reusing some without permission? GWT has the same basic issue, the CLA isn't just about allowing Google to use the code, but also the contributor's guarantee that they have the rights to commit the changes they are making.

[Benjamin Possolo]

Thanks for the detailed response.

On Saturday, March 29, 2014 7:28:22 PM UTC-7, Thomas Broyer wrote:

Do you imply that the same system that is used for Android and ChromiumOS lacks credibility? The same that's also used by Eclipse, OpenStack, Typo3, Qt, Wikimedia, etc. https://code.google.com/p/gerrit/wiki/ShowCases

I think simple things like having a View On GitHub button, the Fork This Project on GitHub ribbon and the silhouette of the GitHub mascot on the GWT project site would all provide more credibility and charm to lure people to the project.

I think other UI frameworks/platforms like AngularJS are gaining more traction/adoption because they are accessible through GitHub.

 

I agree GitHub is more familiar to many than Gerrit, and that would probably ease contributions.

But, as far as I'm concerned, I wouldn't move to GitHub (at least for GWT proper).

The main reasons we chose Gerrit were:

* side-by-side diffs

* enforcing a clean history (this is particularly important as Google syncs their internal Perforce repo with the public Git repo, the history needs to be linear for them)

The website doesn't have those "clean history" constraints, but it'd be a bit strange to use another system to review changes for the website than changes to GWT proper (note that I'm not strongly against it)

I believe you can find some discussions on the subject in the archives of https://groups.google.com/d/forum/gwt-steering

At GitHub, to maintain a clean history means that you either ask every contributor to rebase and squash their branches before you can merge them, and/or you rebase and squash them yourself when merging, but it at least means being very careful when clicking the "merge" button (so careful that you'd probably want to disable it –that's not possible– and force every commiter to merge manually with --ff-only or --squash).

We're starting seeing integrations between Gerrit and GitHub (http://gerrithub.io/), so who knows, maybe one day that plugin will be available on gwt-reviews so contributors will be able to submit changes as GitHub Pull Requests rather than pushing them to Gerrit.

i think side-by-side diffs can always be attainted through a 3rd party tool. if the contribution is small i don't see the big advantage. if the contribution is very big you're likely going to pull the branch yourself to examine/run it. 

 

At my current workplace, we ensure our main project repo has a "clean" history as well by having developers:

1. fork the main repo
2. commit/squash/push to their personal repo
3. send pull requests from their personal repo to the main repo
   

In the mean time, I believe what we need is better documentation. Our "making GWT better" web page is really light. Patches welcome.

The webpage improvements should be a different discussion but I think it needs a much bigger overhaul in order to "productize" it more.

Ideally it would be competitive with other sites like AngularJS (http://angularjs.org), Scala (http://scala-lang.org), Google Cloud Platform & GAE (https://cloud.google.com), EmberJS (http://emberjs.com), IntercoolerJS (http://intercoolerjs.org), etc.

There are tons of projects built on GWT which is fantastic but there is hardly any talk about it and almost nothing on Hacker News which is kind of sad.

 

I think it would also help us if we got GWT on the radar of services like Prerender (https://prerender.io), SEOjs (http://getseojs.com), Brombone (http://www.brombone.com), etc which would help drive home the fact that it's a serious product that is viable for enterprise and public facing sites.

 

Not to mention, it is simply much more social and transparent.

!?

I could understand the "more social" argument (although I don't think it's a compelling one), but "more transparent"?

The two are very intertwined in my eyes. Having recognizable people/users from other popular projects on github starring, commenting and contributing to GWT along with an easier to use interface yields a higher amount of perceived transparency.

It sounds like Gerrit has a feature that only allows patches from people that have signed contributor legal agreements.

I guess I don't really understand why this is necessary now that GWT has become fully open sourced and is no longer owned by Google.

Required reading: http://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ and http://www.clahub.com/pages/why_cla

Ideally, the GWT Project would be a legal organization so you'd sign a CLA with the GWT Project. But it's not, so you still sign an agreement with Google.

Yes, there are things like CLAHub; but you need to train all committers to not look at patches until the CLA has been signed, it's not enforced.

Similarly, GitHub hooks with the PR status API can inform you of the build status of a pull request, but nothing prevents you from merging it. On the other hand, merging a change that fails to build in Gerrit needs special permissions (even though we don't do a full build, so in practice a change can still break the build without failing the pre-check)

That was insightful reading. thank you.

why does an implicit agreement to abide by the terms of a CLA upon pull request not suffice?

isn't the source code license implicitly agreed to when its downloaded/used within another project?

the bits about "poisoned commits" seem plausible but the CLA doesn't physically prevent this from happening. I guess it just allows easier finger pointing in the rare event that such a scenario arises.

[Stephen Haberman]

> We're starting seeing integrations between Gerrit and GitHub
> (http://gerrithub.io/)

Ooh, that looks spiffy. Thanks for the link, Thomas.

From Benjamin's reply:

> I think other UI frameworks/platforms like AngularJS are gaining more
> traction/adoption because they are accessible through GitHub.

AngularJS is not gaining more traction than GWT merely because it's
hosted on GitHub. I wish that there the case (what an easy thing to
fix!), but in reality it's much more than that, and not worth rehashing
here.

Basically, Benjamin, it's great to have you, and I'm sure you mean
well, but you're not going to win a "let's change our tools" thread on
your 1st post to gwt-contrib.

But it's great to see that you're enthusiastic about GWT. It'd be great
to have you help out. Perhaps you can indulge us and put up with Gerrit
for awhile while doing so. :-)

- Stephen

[Benjamin Possolo]

yah i don't actually expect it to happen just because i created a thread about it. i was just wondering if there are any very strong reasons against it.

with regards to angularjs adoption...yes you are right in that it's not just the code repository but i feel like some "simple" changes would help bring GWT up to the playing field of several of the other trendy frameworks. I've had trouble convincing people to consider GWT because on the surface-level, it seems less mature when in reality the opposite is true.

[Joel Handwell]

Is there any update on considering http://gerrithub.io/ ?

[Thomas Broyer]

On Friday, December 12, 2014 3:10:19 AM UTC+1, Joel Handwell wrote:

Is there any update on considering http://gerrithub.io/ ?

No.

The website will probably move to GitHub, but the GWT code will stay on Gerrit.

(as an aside: Go –the programming language– has just moved out of code.google.com to the same tools that we use for GWT, except they also moved their issues and wiki over to GitHub; but the code is only mirrored to GitHub, contributions go through Gerrit)