
Golang on GitHub - brendanashworth
https://github.com/golang/go
======
dsymonds
This was announced in mid November: [https://groups.google.com/d/topic/golang-
dev/sckirqOWepg/dis...](https://groups.google.com/d/topic/golang-
dev/sckirqOWepg/discussion)

To be clear, Go is not "on" GitHub except for its issue tracker and wiki. The
code is being developed, reviewed and submitted on
[https://go.googlesource.com](https://go.googlesource.com), using similar
infrastructure to Android and Chromium.

~~~
Xeoncross
So, that c/go code I see in the repository isn't actual code or...?

~~~
pluma
It's a mirror, as I understand it.

------
W0lf
Did someone else notice the c joke (?) in the first 3-4 commits?

~~~
sanxiyn
Unfortunately, this joke makes GitHub Graphs page much less useful, because
graphs start from 1972.

[https://github.com/golang/go/graphs/contributors](https://github.com/golang/go/graphs/contributors)

Is there a way to get this fixed?

~~~
Cederfjard
It's not that big a deal, is it? You can just narrow the span down like this:
[http://cl.ly/image/3A12032B3Q2O](http://cl.ly/image/3A12032B3Q2O)

------
nemothekid
Its actually pretty cool that all the google code issues got turned GitHub
issues, in the same exact order as the google code issues such that the issues
numbers are still consistent on Github.

~~~
blowski
I'm guessing they did it with an import script - something like
[http://www.iqandreas.com/github-issues-
import/configuration/...](http://www.iqandreas.com/github-issues-
import/configuration/#enterprise)

~~~
giovannibajo1
I went through a similar migration last month for PyInstaller, and we couldn't
find a way to set the original date for issues/comments; the best solution was
to add the date/time as part of the comment; see just one example here:
[https://github.com/pyinstaller/pyinstaller/issues/830](https://github.com/pyinstaller/pyinstaller/issues/830)

The script you linked does the same (we used a different now). We even
contacted GitHub and they said we were out of luck, very sorry.

Now, I see golang has perfectly migrated all the timestamps. I wonder how they
did that. If they used some private APIs, I would be _very_ annoyed with
GitHub support.

------
peterwaller
It's unfortunate that it isn't possible to disable pull requests. There is
already noise appearing there, which will always be a wart so long as pull
requests can't be disabled.

~~~
ishityounot
Noise? That's how contributions are called now?

~~~
nemothekid
Go already has an established contributing process, and people who make PRs
without bothering to understand that process are likely just making noise.

~~~
CornishPasty
In that case why are they using GitHub?

~~~
vertex-four
GitHub provides _the_ best web-based git repository browser, as well as
various other useful features. The only other reasonable alternative for a
large open-source project, aside from self-hosting, is bitbucket.

~~~
sfk
I disagree. GitHub looks cluttered and the contrast is too low for speed
reading. I prefer the hg interface, for example:

[https://hg.python.org/cpython/](https://hg.python.org/cpython/)

Another interface I prefer is:

[http://cvsweb.openbsd.org/cgi-bin/cvsweb/](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/)

~~~
oblio
You like cvsweb? It's horrible. I'm here: [http://cvsweb.openbsd.org/cgi-
bin/cvsweb/CVSROOT/](http://cvsweb.openbsd.org/cgi-bin/cvsweb/CVSROOT/). Why
does not clicking a file open the file?!?!? Every freaking file browser in
existence opens the file when I click it. It's been designed in the 90s and it
shows :(

------
Spiritus
I'm getting 404, has it been removed?

~~~
dsymonds
Unfortunately a significant problem was just found in the process for
migrating the issues from code.google.com to GitHub. We're going to re-do the
migration, but need to lock down the repo so we don't blow away anything that
someone might enter.

It should be back soon-ish.

------
farresito
This is the gerrit link, I believe: [https://go-
review.googlesource.com](https://go-review.googlesource.com)

------
shawnps
Did anyone do anything special to get their contributions attributed to their
GitHub account? Mine are not showing up here:
[https://github.com/golang/go/graphs/contributors](https://github.com/golang/go/graphs/contributors)

~~~
dsymonds
See [https://help.github.com/articles/why-are-my-contributions-
no...](https://help.github.com/articles/why-are-my-contributions-not-showing-
up-on-my-profile/).

The most likely reasons are:

    
    
      - your email address used for your Go contribution is not associated with your GitHub account
      - your contribution is over a year old
      - you haven't starred the project

~~~
shawnps
Interesting, I'll star the project and see what happens. I see other people's
contributions showing up that are over 1 year old so I'm not sure if that is
why.

------
sanxiyn
I find it interesting that Rust has a lot more contributors compared to Go.
Comparing [https://github.com/golang/go](https://github.com/golang/go) and
[https://github.com/rust-lang/rust](https://github.com/rust-lang/rust), all
contributors: 380 vs 695, contributors with more than 100 commits: 17 vs 35.

~~~
fhs
Keep in mind that contributing to Go requires that you sign a contributor
license agreement, something people might not want to go through (no pun
intended) for small changes.

~~~
untothebreach
I believe Rust requires a CLA as well. Might be wrong, but I seem to remember
getting a mail about that a while back. A rust dev that knows for sure can
correct me, if necessary.

~~~
brson
Rust does not require a CLA.

~~~
DannyBee
Not quite right. "Those with review privileges or direct push access are
required to file a Mozilla "committer agreement". "

(FWIW: From a legal standpoint, this doesn't make any sense. Either all-in or
all-out makes sense. There is no legal distinction to be drawn that the above
captures, AFAIK)

~~~
pcwalton
See the committer agreement section 4, which covers this case:
[https://static.mozilla.com/foundation/documents/commit-
acces...](https://static.mozilla.com/foundation/documents/commit-
access/committers-agreement.pdf)

All code committed to the Rust repository goes through someone who has signed
a CLA, including this section.

Rust uses the same policies here as Firefox.

~~~
DannyBee
So does this mean all original code (IE not third party code) requires a CLA?

Or not?

If so, then Rust requires CLAs. Great, legally sound.

If not, this makes no legal sense. Simply having people with a CLA commit it
buys you nothing, legally :)

As I said, all-in and all-out policies make sense. Pass through policies (IE i
can commit code by another), you may as well have no CLA. It's just overhead
with no legal benefit. The benefit of CLA's is to have legal assertions about
ownership and patents, _from the people who wrote the code_.

So without having the people who _actually wrote the code_ make those
assertions, you get nothing legally.

In those cases, or if it isn't your goal (like the DCO folks), you might as
well move to the developers certificate of origin model, and get the same
benefits, without any of the overhead.

~~~
kibwen
The process is as follows:

1\. Any Github user submits a PR. This user is not required to have a name or
a valid email address.

2\. Anyone with review access to the Rust repository (disclaimer: myself
included) reviews the PR and leaves a comment on the commit. A bot sees the
comment and queues the PR for integration.

I can't comment on the legal implications, but the effect of this process is
that there is a very low barrier to entry to contributing and likely explains
why the total number of contributors (as measured by Github) is so high.

As to the issue of potential relicensing, the Rust repo is already about as
permissively licensed as it gets (a dual license of MIT/Apache 2.0). As far as
I understand, this already means that anyone can take the code and relicense
it at will (I believe this is exactly what LibreOffice did to OpenOffice). At
that point you'd probably still need to distribute the MIT license with each
of the original files, but new contributions (and the project as a whole)
would be covered by GPL or what have you.

~~~
DannyBee
So, given this process, there is literally no advantage to having anyone sign
legal agreements, at all. I don't expect Mozilla to change, of course. :)

As for relicensing:

Both MIT and Apache require copyright notices be reproduced when you ship
binaries. I'll assume MIT since it is the more permissive (Apache also
requires you give the user a copy of the license, etc).

Rust is statically linked by default, IIRC (and even shared linking often ends
up with some runtime code statically linked in).

If Rust binaries include parts of the MIT code by default (I haven't looked at
how the runtime and ABI support is structured), then anyone who ships those
binaries would be required to reproduce the copyright notice somewhere.

You cannot take this code and relicense it at will, actually. But you can
achieve the same practical effect as relicensing, as long as you reproduce the
notice, so i won't get into it unless you really want me to :)

(But note that reproducing the notice is exactly the issue for runtime
libraries, and without CLA's in place, you would hav to go and ask all
contributors who have ever contributed to the runtime libraries in order to be
able to remove that notice reproduction requirement)

~~~
kibwen

      > If Rust binaries include parts of the MIT code by default 
      > (I haven't looked at how the runtime and ABI support is 
      > structured), then anyone who ships those binaries would 
      > be required to reproduce the copyright notice somewhere.
    

This contradicts other projects that I've seen. From LLVM's documentation
([http://llvm.org/docs/DeveloperPolicy.html#license](http://llvm.org/docs/DeveloperPolicy.html#license)):

 _" In addition to the UIUC license, the runtime library components of LLVM
(compiler_rt, libc++, and libclc) are also licensed under the MIT License,
which does not contain the binary redistribution clause. As a user of these
runtime libraries, it means that you can choose to use the code under either
license (and thus don’t need the binary redistribution clause), and as a
contributor to the code that you agree that any contributions to these
libraries be licensed under both licenses. We feel that this is important for
runtime libraries, because they are implicitly linked into applications and
therefore should not subject those applications to the binary redistribution
clause."_

The "binary redistribution clause" referenced from the UIUC license
([http://opensource.org/licenses/UoI-
NCSA.php](http://opensource.org/licenses/UoI-NCSA.php)) reads as follows:

 _" Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimers in the documentation
and/or other materials provided with the distribution."_

Given that it seems that LLVM chose MIT specifically to sidestep any need for
end users to distribute licenses with binaries compiled via LLVM, I'd be
curious to know where the discrepancy here is.

~~~
DannyBee
I actually wrote that wording for LLVM, so i'm happy to explain the
discrepancy.

Basically, we messed up when we changed the runtime license (I said MIT
license when I meant zlib license, which only requires reproduction of notices
in the source code), and had to issue a policy statement on the license to
make people happy. It is not accurate, legally, in its description of the MIT
license. Effectively, by this statement, we are giving permission to not
reproduce the notice, even though the license would actually require it.

You don't have to take my word for it though, ask any other open source lawyer
whether MIT requires notice reproduction for binaries.

:)

I would urge Rust not to make the same mistake. (This mistake is currently
being fixed in a few other "new" languages, in fact)

~~~
kibwen
What a hilarious coincidence. :)

I'm guessing you can't go giving out concrete legal advice for free, but could
you point us towards languages that are fixing this? I see that Julia's stdlib
uses MIT for non-external libraries,[1] and Go uses a BSD-style license that
explicitly requires distributing the license with binaries,[2] so they're both
in the same boat we are. AFAICT D's stdlib uses the Boost license[3] which
explicitly allows one to forgo distributing the license with compiled
artifacts, but I don't know if solving this issue entirely would require the
entire compiler to be licensed under Boost as well. Presuming that interpreted
languages can gracefully ignore this issue, I don't know which other "new"
languages we could look at for inspiration.

[1]
[https://github.com/JuliaLang/julia/blob/master/LICENSE.md](https://github.com/JuliaLang/julia/blob/master/LICENSE.md)

[2]
[https://github.com/golang/go/blob/master/LICENSE](https://github.com/golang/go/blob/master/LICENSE)

[3] [https://github.com/D-Programming-
Language/phobos/blob/master...](https://github.com/D-Programming-
Language/phobos/blob/master/LICENSE_1_0.txt)

~~~
pcwalton
> I'm guessing you can't go giving out concrete legal advice for free, but
> could you point us towards languages that are fixing this?

Please note that kibwen is not part of the core Rust team.

~~~
DannyBee
Sure, but note:

If you don't fix this, you end up with two situations:

1\. You accidentally create copyright infringers out of a lot of folks,
because the number of people who will properly reproduce the license with
static binaries is small.

2\. Because of #1, you expose folks to a bunch of liability they weren't
expecting.

Neither is a great thing to do to your users.

Combined with the fact that you don't have CLA's that grant you explicit
sublicensing rights, anyone who contributes could go off and easily have a
sane case against someone for not reproducing the notice. Statutory damages
for copyright infringement are up to 150k in the US, sadly.

Anyway, as for other languages, this is being fixed for Go's runtime bits (and
possibly stdlib), which i can talk about, but it's not really my secret to
share in the case of the other languages I know about fixing it.

~~~
kibwen

      > Anyway, as for other languages, this is being fixed for 
      > Go's runtime bits (and possibly stdlib), which i can talk 
      > about
    

Even if I have no power to change anything about Rust myself, if you care to
advise I'd love to listen and potentially pass on your wisdom to the core
team. And if you'd prefer a different medium than HN comments, you can find my
email in my profile. :)

------
comex
Hmm - how did they manage to backdate the issue/issue comment creation? I
don't see it in the GitHub API documentation.

~~~
bradfitz
Special process, working with support@github.com. They have an internal tool
that will migrate a special format (which we had to prepare). After 14 tries,
we got it right. Mostly. We still couldn't do lots of things we wanted, but it
was way better than our first version where we did it all via API calls.

~~~
comex
A (much smaller) project I contribute to might want to similarly migrate
issues from Google Code to GitHub. It would be nice if backdating were
available via a standard API, but I guess it's not terribly important for us.
A bigger problem is that we'd like issue numbers to have a 1:1 mapping, but
we're already using GitHub for pull requests, and pull requests are issues, so
something would have to give... however, if we could specify arbitrary
(unused) IDs, we could do something like add 100000 to the old issue numbers.
Just thinking out loud.

------
bhaavan
If you go to that link you might get 404. You can go to
[https://github.com/golang/](https://github.com/golang/) to explore. Once you
go there, you might see go as a project too.

Go overuse is purely intended.

------
LunaSea
How come the number of issues is that high ?

~~~
copx
The number is not that high at all. I only see 1,289 open issues. To compare
the D issue tracker has 3,677 open issues right now and the D user and
developer community is tiny compared to the Go community.

Also note that "issue" does not necessary mean "bug". Such trackers are also
used to request features just like in this case. Many of the D and Go "issues"
are actually feature requests.

------
krzrak
...aaaand it's gone

------
azatris
I'd like to mention that for me personally the biggest issues with the
language so far is its unappealing name.

'Go' sounds like a bad sports drink.

Does anyone think the same?

Is it for the greater good to be inviting for more pragmatic thinkers (instead
of people who care about aesthetics)?

~~~
psaintla
If you choose your tools based on the naming you're going to have very few
left to work with.

