|
|
|
|
|
|
by hierro
4762 days ago
|
|
|
The only things that really bothers me about Go is how difficult is to contribute a patch (even when I'm listed as a contributor). First, you have to sign an agreement to give an unlimited license to Google to use your code as they see fit, then you have to use a special HG extension to get your patches uploaded to codereview.google.com (which disables branches/commits/etc, and doesn't let you submit multiple patches affecting the same files) and, finally, the patches may sit in review for a few weeks until someone from the core dev team takes a look at them. |
|
|
1. CLAs are a fact of life in open source to keep the lawyers happy (http://en.wikipedia.org/wiki/Contributor_License_Agreement). We've tried to make it as simple as possible: you fill out one web form, we do the rest. And it's just once, not every time. So if you're already listed as a contributor, you're done with this forever.
2. You're free of course to prepare the code any way you want. We insist on the hg extension to manage the review of the patch, mainly because it makes our lives easier: there are a LOT more contributors than there are core Go team members doing code reviews. (And we don't just review; sometimes we even like to write our own code.) I hope using the tool isn't really too burdensome. Many people work with other things, like git in the same dir or hg in another dir, and then they copy the changes into their "review" tree.
3. This is a real problem. We don't have a good system for tracking these: so far we've just been letting everyone watch the same stream and deal with what needs dealing with. But the volume has gotten high enough that we are dropping too many incoming changes or bug reports on the floor. We're working on a new system to track incoming changes and bug reports and assign them to a clear owner so that everyone knows who is responsible for what. I hope this will go live soon.