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. On Saturday, March 29, 2014 9:28:22 PM UTC-5, Thomas Broyer wrote: > > > > On Sunday, March 30, 2014 3:41:33 AM UTC+2, Benjamin Possolo wrote: >> >> I am interested in helping "modernize" the >> gwtproject.orgwebsite/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-813480084I'd > be interested in knowing the reasons for the change. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
