Golang on GitHub(github.com)
github.com
Golang on GitHub
https://github.com/golang/go
14 comments
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.
I'm guessing they did it with an import script - something like http://www.iqandreas.com/github-issues-import/configuration/...
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
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.
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.
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.
[deleted]
Noise? That's how contributions are called now?
No, it's just that the Go team have decided to continue with their current contribution process rather than using pull requests. I don't know whether this is a permanent decision or not.
"The Go team will not be accepting pull-requests here. Contributions must still go through the normal code-review process and gerrit. The updated contribution steps are not yet available though."
https://github.com/golang/go/pull/9219
"The Go team will not be accepting pull-requests here. Contributions must still go through the normal code-review process and gerrit. The updated contribution steps are not yet available though."
https://github.com/golang/go/pull/9219
This is something very similar to that is being planned for FreeBSD repositories on GitHub: automated process turning pull requests into FreeBSD's Bugzilla bug reports and a comment closing the pull request, informing user about the Bugzilla bug link and how to proceed.
Actually that's even better than disabling pull requests entirely. I guess the closing comment will also contain a link to contribution guidelines and such.
Edit: @rurounijones points out that if there's a CONTRIBUTING.md in the repo then Github will show it when someone creates a PR. That's a great feature!
Edit: @rurounijones points out that if there's a CONTRIBUTING.md in the repo then Github will show it when someone creates a PR. That's a great feature!
Github PRs are noise when the contribution workflow does not use PRs.
Go's contribution workflow does not use PRs.
Go's contribution workflow does not use PRs.
Yes, when they are on a mirror of a code repo. The upstream repo is at https://go.googlesource.com/go
Go already has an established contributing process, and people who make PRs without bothering to understand that process are likely just making noise.
Is their contributing process described in README or in some other file within the repo?
There is, but since we're only partway through migrating to git/github, the README still shows the old instructions. The new contribution instructions will appear here in the next few days: http://golang.org/doc/contribute.html
Not that it really matters, right now, as we're in a pre-release freeze.
Not that it really matters, right now, as we're in a pre-release freeze.
Make sure there is a CONTRIBUTING.md file in the repo and Github will automatically highlight it to be read when someone opens a PR
Great suggestion, thank you!
In that case why are they using GitHub?
GitHub is only a mirror. The real work is happening on go.googlesource.com.
https://groups.google.com/d/topic/golang-dev/sckirqOWepg/dis...
https://groups.google.com/d/topic/golang-dev/sckirqOWepg/dis...
Linux is on Github as well (https://github.com/torvalds/linux) , and probably like Linus, some people don't like the Pull-request method for dealing with contributions.
Linux is on https://git.kernel.org/cgit/ .
And go is technically on https://go.googlesource.com/go
Interesting that the git hipsters are downvoting factually correct information. "Unruly hackers" (pg) seem to be perfect fodder for groupthink and monopolies.
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.
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/
Another interface I prefer is:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/
https://hg.python.org/cpython/
Another interface I prefer is:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/
You like cvsweb? It's horrible. I'm here: 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 :(
ironically there is an ongoing discussion on python-devel to migrate from hg to git+github
IMHO it's an error, but I am not a core python developer
IMHO it's an error, but I am not a core python developer
I would like to disagree with the "the best". Mostly because it's obviously your opinion and not something you can say definitely.
Sometimes you have to learn to trust your opinion too -- and to learn to access others opinions when there are no definite answers.
Lot of replies here disagreeing that GitHub is "the best", and offering alternatives.
Allow me to suggest that GitHub is at minimum the most-visited web-based git repo, which means that if you want a lot of people to view and use your code, it's a good place to mirror.
Allow me to suggest that GitHub is at minimum the most-visited web-based git repo, which means that if you want a lot of people to view and use your code, it's a good place to mirror.
> GitHub provides the best web-based git repository browser
I like Bitbucket's side-by-side diff view so much, that I think I prefer Bitbucker for browsing.
But this is only because Bitbucket has the side-by-side diff view, anf GitHub does not.
I like Bitbucket's side-by-side diff view so much, that I think I prefer Bitbucker for browsing.
But this is only because Bitbucket has the side-by-side diff view, anf GitHub does not.
Could you describe what makes it the best repository browser?
I like e.g. https://trac.openstreetmap.org/browser/chef
I like e.g. https://trac.openstreetmap.org/browser/chef
So that they have the wiki+issues stuff.
This is the gerrit link, I believe: https://go-review.googlesource.com
This was announced in mid November: https://groups.google.com/d/topic/golang-dev/sckirqOWepg/dis...
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, using similar infrastructure to Android and Chromium.
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, using similar infrastructure to Android and Chromium.
I'm getting 404, has it been removed?
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.
It should be back soon-ish.
[deleted]
[deleted]
...aaaand it's gone
If you go to that link you might get 404. You can go to https://github.com/golang/ to explore. Once you go there, you might see go as a project too.
Go overuse is purely intended.
Go overuse is purely intended.
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
See https://help.github.com/articles/why-are-my-contributions-no....
The most likely reasons are:
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 projectInteresting, 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.
Do you have the mail address you used for your contribution in the set of github email addresses? (https://github.com/settings/emails)
Just added it now, perhaps it will update. I'll check back on it later, thanks.
I think it's because of the distinction of Author and Committer. I also don't see my name there: https://github.com/golang/tools/commits/master/cmd/cover/fun...
No, it's because the page only tracks the top 100 contributors, the cutoff is currently 6 commits.
For instance "spaolacci" is #86 with 8 commits, he's only ever been an author not a committer: https://github.com/golang/go/commits?author=spaolacci
For instance "spaolacci" is #86 with 8 commits, he's only ever been an author not a committer: https://github.com/golang/go/commits?author=spaolacci
I'm not sure about that either, I have 32 commits:
➜ go hg log --user "Shawn Smith" | grep user | wc -l
32
Edit: I'm there now. Not sure what fixed it, starring the repo or adding my email address to GitHub.
➜ go hg log --user "Shawn Smith" | grep user | wc -l
32
Edit: I'm there now. Not sure what fixed it, starring the repo or adding my email address to GitHub.
Btw, you can avoid the grep in hg using a simple template:
http://mercurial.selenic.com/wiki/GenericTemplatingPlan
Edit: Oh, oh, and another way to count without even using wc -l, using the churn extension and a revset!
hg log --user "Shawn Smith" --template "{rev}:{author}\n" | wc -l
http://mercurial.selenic.com/wiki/GenericTemplatingPlan
Edit: Oh, oh, and another way to count without even using wc -l, using the churn extension and a revset!
hg --config extensions.churn= churn -r "user('Shawn Smith')" -c
hg churn -r "user('Shawn Smith')" -c
[deleted]
[deleted]
Did someone else notice the c joke (?) in the first 3-4 commits?
https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...
https://github.com/golang/go/commit/0bb0b61d6a85b2a1a33dcbc4...
https://github.com/golang/go/commit/0744ac969119db8a0ad32539...
https://github.com/golang/go/commit/d82b11e4a46307f1f1415024...
So these are actually commits from the C language? Or are they spoofed?
Obviously there wasn't Git back then, but did they use some sort of version control when developing C?
Obviously there wasn't Git back then, but did they use some sort of version control when developing C?
> Obviously there wasn't Git back then, but did they use some sort of version control when developing C?
I'm gonna guess printouts.
I'm gonna guess printouts.
R=dmr
RIP Dennis.
RIP Dennis.
Unfortunately, this joke makes GitHub Graphs page much less useful, because graphs start from 1972.
https://github.com/golang/go/graphs/contributors
Is there a way to get this fixed?
https://github.com/golang/go/graphs/contributors
Is there a way to get this fixed?
It's not that big a deal, is it? You can just narrow the span down like this: http://cl.ly/image/3A12032B3Q2O
You could file a bug against GitHub.
Maybe they could also fix their recognition of email addresses to permit `<research!bwk>` too.
Maybe they could also fix their recognition of email addresses to permit `<research!bwk>` too.
You can select a timeframe like this:
https://github.com/golang/go/graphs/contributors?from=2008-0...
Hah, that's funny. Give credit where credit is due.
How come the number of issues is that high ?
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.
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.
Rust has 2,163 issues at the moment, compared to Go's 1,289.
It's been a very active open source project for over five years. It's roughly 5 issues per week.
I find it interesting that Rust has a lot more contributors compared to Go. Comparing https://github.com/golang/go and https://github.com/rust-lang/rust, all contributors: 380 vs 695, contributors with more than 100 commits: 17 vs 35.
I've made several CLs like this commit [1], yet I am not seeing myself listed under contributors.
[1] https://github.com/golang/go/commit/912ec1990bd09f8fc128c3fa...
[1] https://github.com/golang/go/commit/912ec1990bd09f8fc128c3fa...
I believe the .../graphs/contributors page only shows the top 100 contributors (for Go it looks like the threshold for commits is approximately 6).
You're right, but that's not the reason here. That's with the default filter; you can adjust the date range, or show based on lines added/removed, and I'm still not showing up even in cases when it shows less than 100 people and/or with less total lines added/removed than my commits.
One thing I love in Rust is that it purely makes use of the existing infrastructure that everybody knows - GitHub.
Every Google project uses its own repository, issue tracker, and mailing list. Even many Mozilla projects such as SpiderMonkey require some knowledge to access their infrastructure. However, almost all development in Rust are done only using GitHub. No external dependencies. One exception that is not part of GitHub would be the build bot, though it doesn't matter much.
I know that GitHub centralization is not a good sign, but Rust's all-in-one approach really lowers the barrier to entry significantly.
Every Google project uses its own repository, issue tracker, and mailing list. Even many Mozilla projects such as SpiderMonkey require some knowledge to access their infrastructure. However, almost all development in Rust are done only using GitHub. No external dependencies. One exception that is not part of GitHub would be the build bot, though it doesn't matter much.
I know that GitHub centralization is not a good sign, but Rust's all-in-one approach really lowers the barrier to entry significantly.
Buildbot and Bors are also hosted on Github. :D
https://github.com/rust-lang/rust-buildbot https://github.com/graydon/bors/tree/rust
https://github.com/rust-lang/rust-buildbot https://github.com/graydon/bors/tree/rust
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.
[deleted]
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.
Rust does not require a CLA.
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)
(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)
See the committer agreement section 4, which covers this case: https://static.mozilla.com/foundation/documents/commit-acces...
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.
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.
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.
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.
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.
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.
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)
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)
> 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.
"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) 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.
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)
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)
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
[2] https://github.com/golang/go/blob/master/LICENSE
[3] https://github.com/D-Programming-Language/phobos/blob/master...
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
[2] https://github.com/golang/go/blob/master/LICENSE
[3] https://github.com/D-Programming-Language/phobos/blob/master...
The Mozilla committer agreement is not a CLA as I understand the term - it does not assign copyright to Mozilla, copyright is retained by the original author. The purpose of the document is to assert that those contributing code have the legal authority to do so. In Rust's case, those with review power are the gatekeepers responsible for ensuring the provenance of the code.
> it does not assign copyright to Mozilla
This is common to many CLAs (sane ones, at least). The Go CLA (really the Google CLA[1]) also does not assign copyright to the Go project, it gives them a license to "reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works"
[1] https://cla.developers.google.com/about/google-individual
This is common to many CLAs (sane ones, at least). The Go CLA (really the Google CLA[1]) also does not assign copyright to the Go project, it gives them a license to "reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works"
[1] https://cla.developers.google.com/about/google-individual
CLA = Contributor License Agreement
No license agreement should be assigning copyright.
IE All CLA's should be licenses, not assignments.
Any project with a copyright assignment doesn't have a CLA, they have a copyright assignment. :)
No license agreement should be assigning copyright.
IE All CLA's should be licenses, not assignments.
Any project with a copyright assignment doesn't have a CLA, they have a copyright assignment. :)
BUT this allows for easier changing of the licensing.
That's a "feature"? (from a contributor perspective)
Sorry I should have put a sarcasm tag :P
A fairly large number of projects decide to change their license later in life, but this is mostly if they start off with more "restrictive" (for lack of a better term, i know how Free software advocates feel about this) licenses, like GPLv3 or whatever, or because they discover the license doesn't work well for what they wanted.
For example, Eigen, a very widely used math library, switched licenses because they were mistaken about the implications of LGPL, and as it started getting more widely used, it started affecting usage.
Other projects grow runtime libraries, and discover they don't want licenses that require attribution for those, because then everyone who makes a binary has to ship notices, etc.
There are even simpler cases.
For example, llgo, the Go language frontend for LLVM, is being contributed to the LLVM project. This requires a license change to the same license as LLVM. Because there were no contributor agreements, every contributor had to be tracked down and asked. A bunch are either dead or not around anymore, and now those contributions have to be rewritten or excised. This has slowed them down a few months so far (at least from my view, pcc can surely correct me if it hasn't been that long)
In terms of how often this happens, i've personally helped about 50 medium-high profile open source projects change licenses, and it's not even my "real job". It's fairly common that as a project goes from nothing to having a lot of users, they end up having to change something about their licensing.
It's also a massive pain when there are no CLA's.
For example, Eigen, a very widely used math library, switched licenses because they were mistaken about the implications of LGPL, and as it started getting more widely used, it started affecting usage.
Other projects grow runtime libraries, and discover they don't want licenses that require attribution for those, because then everyone who makes a binary has to ship notices, etc.
There are even simpler cases.
For example, llgo, the Go language frontend for LLVM, is being contributed to the LLVM project. This requires a license change to the same license as LLVM. Because there were no contributor agreements, every contributor had to be tracked down and asked. A bunch are either dead or not around anymore, and now those contributions have to be rewritten or excised. This has slowed them down a few months so far (at least from my view, pcc can surely correct me if it hasn't been that long)
In terms of how often this happens, i've personally helped about 50 medium-high profile open source projects change licenses, and it's not even my "real job". It's fairly common that as a project goes from nothing to having a lot of users, they end up having to change something about their licensing.
It's also a massive pain when there are no CLA's.
Also contributors are not the same as committers in Github. And I've found that Github doesn't display Authors but only Committers. Example: https://github.com/golang/tools/commits/master/cmd/cover/fun...
Github does display both author and committer, and has for some time. If an author is present, it's the contributor.
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)?
'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)?
If you choose your tools based on the naming you're going to have very few left to work with.
I don't use Java because I'm more of a tea drinker.
To me "Go" is associated with the game Go/Baduk.
Which happens to be a amazing game not only for abstract thinkers, but for aesthetic beauty.
Which happens to be a amazing game not only for abstract thinkers, but for aesthetic beauty.
Thanks guys, the amount of negative votes lets me know I should change my perception of it, because I'm likely the minority. I thought this is an issue if we want to invest in the future of a language, but apparently it isn't.
[deleted]
Hmm - how did they manage to backdate the issue/issue comment creation? I don't see it in the GitHub API documentation.
Special process, working with [email protected]. 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.
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.