10 ms·

Golang on GitHub

peterwaller 12y ago
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 12y ago
  Noise? That's how contributions are called now?
  - colinramsay 12y ago
    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 https://github.com/golang/go/pull/9219
    - tachion 12y ago
      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.
      - colinramsay 12y ago
        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!
  - iand 12y ago
    Yes, when they are on a mirror of a code repo. The upstream repo is at https://go.googlesource.com/go https://go.googlesource.com/go
  - nemothekid 12y ago
    Go already has an established contributing process, and people who make PRs without bothering to understand that process are likely just making noise.
    - CornishPasty 12y ago
      In that case why are they using GitHub?
      - nemothekid 12y ago
        Linux is on Github as well (https://github.com/torvalds/linux https://github.com/torvalds/linux) , and probably like Linus, some people don't like the Pull-request method for dealing with contributions.
        sfk 12y ago
        Linux is on https://git.kernel.org/cgit/ https://git.kernel.org/cgit/ .
        sfk 12y ago
        Interesting that the git hipsters are downvoting factually correct information. "Unruly hackers" (pg) seem to be perfect fodder for groupthink and monopolies.
        nemothekid 12y ago
        And go is technically on https://go.googlesource.com/go https://go.googlesource.com/go
      - dsymonds 12y ago
        GitHub is only a mirror. The real work is happening on go.googlesource.com. https://groups.google.com/d/topic/golang-dev/sckirqOWepg/discussion https://groups.google.com/d/topic/golang-dev/sckirqOWepg/dis...
      - vertex-four 12y ago
  - masklinn 12y ago
    Github PRs are noise when the contribution workflow does not use PRs. Go's contribution workflow does not use PRs.
- ivank 12y ago
  I've seen projects solve this problem by keeping a pull request open that indicates where contributions should go instead.
  - jbrooksuk 12y ago
    That still doesn't prevent people blindly creating a new pull request though.
- deleted 12y ago
  [deleted]
farresito 12y ago
This is the gerrit link, I believe: https://go-review.googlesource.com https://go-review.googlesource.com
dsymonds 12y ago
This was announced in mid November: https://groups.google.com/d/topic/golang-dev/sckirqOWepg/discussion 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 https://go.googlesource.com, using similar infrastructure to Android and Chromium.
- throwaway2347 12y ago
  LAME. Golang doesn't even have generics. Please add generics support before wasting any more time on configuration management trooling.
- Xeoncross 12y ago
  So, that c/go code I see in the repository isn't actual code or...?
  - pluma 12y ago
    It's a mirror, as I understand it.
nemothekid 12y ago
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 12y ago
  I'm guessing they did it with an import script - something like http://www.iqandreas.com/github-issues-import/configuration/#enterprise http://www.iqandreas.com/github-issues-import/configuration/...
  - giovannibajo1 12y ago
    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.
Spiritus 12y ago
I'm getting 404, has it been removed?
- dsymonds 12y ago
  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.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
throwaway28346 12y ago
LAME. Golang doesn't even have generics. Please add generics first and stop wasting time on configuration management trooling.
krzrak 12y ago
...aaaand it's gone
bhaavan 12y ago
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.
shawnps 12y ago
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
- masklinn 12y ago
  Do you have the mail address you used for your contribution in the set of github email addresses? (https://github.com/settings/emails https://github.com/settings/emails)
  - shawnps 12y ago
    Just added it now, perhaps it will update. I'll check back on it later, thanks.
    - farslan 12y ago
      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/func.go https://github.com/golang/tools/commits/master/cmd/cover/fun...
      - masklinn 12y ago
        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 https://github.com/golang/go/commits?author=spaolacci
        shawnps 12y ago
        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.
W0lf 12y ago
Did someone else notice the c joke (?) in the first 3-4 commits?
- bbrazil 12y ago
  https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae... https://github.com/golang/go/commit/0bb0b61d6a85b2a1a33dcbc418089656f2754d32 https://github.com/golang/go/commit/0bb0b61d6a85b2a1a33dcbc4... https://github.com/golang/go/commit/0744ac969119db8a0ad3253951d375eb77cfce9e https://github.com/golang/go/commit/0744ac969119db8a0ad32539... https://github.com/golang/go/commit/d82b11e4a46307f1f1415024f33263e819c222b8 https://github.com/golang/go/commit/d82b11e4a46307f1f1415024...
  - saljam 12y ago
    R=dmr RIP Dennis.
  - prezjordan 12y ago
    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?
    - Dewie 12y ago
      > Obviously there wasn't Git back then, but did they use some sort of version control when developing C? I'm gonna guess printouts.
- sanxiyn 12y ago
  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?
  - W0lf 12y ago
LunaSea 12y ago
How come the number of issues is that high ?
- dsymonds 12y ago
  It's been a very active open source project for over five years. It's roughly 5 issues per week.
- copx 12y ago
  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.
- sanxiyn 12y ago
  Rust has 2,163 issues at the moment, compared to Go's 1,289.
sanxiyn 12y ago
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 12y ago
  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.
  - baldfat 12y ago
    BUT this allows for easier changing of the licensing.
    - StevePerkins 12y ago
      That's a "feature"? (from a contributor perspective)
      - DannyBee 12y ago
        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.
azatris 12y ago
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)?
- valarauca1 12y ago
  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.
- psaintla 12y ago
  If you choose your tools based on the naming you're going to have very few left to work with.
- snowwrestler 12y ago
  I don't use Java because I'm more of a tea drinker.
- deleted 12y ago
  [deleted]
- azatris 12y ago
  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.
comex 12y ago
Hmm - how did they manage to backdate the issue/issue comment creation? I don't see it in the GitHub API documentation.
- bradfitz 12y ago
  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 12y ago
    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.

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 12y ago
Noise? That's how contributions are called now?
- colinramsay 12y ago
  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 https://github.com/golang/go/pull/9219
  - tachion 12y ago
    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.
    - colinramsay 12y ago
      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!
- iand 12y ago
  Yes, when they are on a mirror of a code repo. The upstream repo is at https://go.googlesource.com/go https://go.googlesource.com/go
- nemothekid 12y ago
  Go already has an established contributing process, and people who make PRs without bothering to understand that process are likely just making noise.
  - CornishPasty 12y ago
    In that case why are they using GitHub?
    - nemothekid 12y ago
      Linux is on Github as well (https://github.com/torvalds/linux https://github.com/torvalds/linux) , and probably like Linus, some people don't like the Pull-request method for dealing with contributions.
      - sfk 12y ago
        Linux is on https://git.kernel.org/cgit/ https://git.kernel.org/cgit/ .
        sfk 12y ago
        Interesting that the git hipsters are downvoting factually correct information. "Unruly hackers" (pg) seem to be perfect fodder for groupthink and monopolies.
        nemothekid 12y ago
        And go is technically on https://go.googlesource.com/go https://go.googlesource.com/go
    - dsymonds 12y ago
      GitHub is only a mirror. The real work is happening on go.googlesource.com. https://groups.google.com/d/topic/golang-dev/sckirqOWepg/discussion https://groups.google.com/d/topic/golang-dev/sckirqOWepg/dis...
    - vertex-four 12y ago
- masklinn 12y ago
  Github PRs are noise when the contribution workflow does not use PRs. Go's contribution workflow does not use PRs.
ivank 12y ago
I've seen projects solve this problem by keeping a pull request open that indicates where contributions should go instead.
- jbrooksuk 12y ago
  That still doesn't prevent people blindly creating a new pull request though.
deleted 12y ago
[deleted]

farresito 12y ago

This is the gerrit link, I believe: https://go-review.googlesource.com https://go-review.googlesource.com

dsymonds 12y ago

This was announced in mid November: https://groups.google.com/d/topic/golang-dev/sckirqOWepg/discussion 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 https://go.googlesource.com, using similar infrastructure to Android and Chromium.

throwaway2347 12y ago
LAME. Golang doesn't even have generics. Please add generics support before wasting any more time on configuration management trooling.
Xeoncross 12y ago
So, that c/go code I see in the repository isn't actual code or...?
- pluma 12y ago
  It's a mirror, as I understand it.

nemothekid 12y ago

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 12y ago
I'm guessing they did it with an import script - something like http://www.iqandreas.com/github-issues-import/configuration/#enterprise http://www.iqandreas.com/github-issues-import/configuration/...
- giovannibajo1 12y ago
  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.

Spiritus 12y ago

I'm getting 404, has it been removed?

dsymonds 12y ago
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.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]

throwaway28346 12y ago

LAME. Golang doesn't even have generics. Please add generics first and stop wasting time on configuration management trooling.

krzrak 12y ago

...aaaand it's gone

bhaavan 12y ago

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.

shawnps 12y ago

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

masklinn 12y ago
Do you have the mail address you used for your contribution in the set of github email addresses? (https://github.com/settings/emails https://github.com/settings/emails)
- shawnps 12y ago
  Just added it now, perhaps it will update. I'll check back on it later, thanks.
  - farslan 12y ago
    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/func.go https://github.com/golang/tools/commits/master/cmd/cover/fun...
    - masklinn 12y ago
      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 https://github.com/golang/go/commits?author=spaolacci
      - shawnps 12y ago
        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.

W0lf 12y ago

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

bbrazil 12y ago
https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae... https://github.com/golang/go/commit/0bb0b61d6a85b2a1a33dcbc418089656f2754d32 https://github.com/golang/go/commit/0bb0b61d6a85b2a1a33dcbc4... https://github.com/golang/go/commit/0744ac969119db8a0ad3253951d375eb77cfce9e https://github.com/golang/go/commit/0744ac969119db8a0ad32539... https://github.com/golang/go/commit/d82b11e4a46307f1f1415024f33263e819c222b8 https://github.com/golang/go/commit/d82b11e4a46307f1f1415024...
- saljam 12y ago
  R=dmr RIP Dennis.
- prezjordan 12y ago
  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?
  - Dewie 12y ago
    > Obviously there wasn't Git back then, but did they use some sort of version control when developing C? I'm gonna guess printouts.
sanxiyn 12y ago
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?
- W0lf 12y ago

LunaSea 12y ago

How come the number of issues is that high ?

dsymonds 12y ago
It's been a very active open source project for over five years. It's roughly 5 issues per week.
copx 12y ago
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.
sanxiyn 12y ago
Rust has 2,163 issues at the moment, compared to Go's 1,289.

sanxiyn 12y ago

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 12y ago
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.
- baldfat 12y ago
  BUT this allows for easier changing of the licensing.
  - StevePerkins 12y ago
    That's a "feature"? (from a contributor perspective)
    - DannyBee 12y ago
      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.

azatris 12y ago

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)?

valarauca1 12y ago
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.
psaintla 12y ago
If you choose your tools based on the naming you're going to have very few left to work with.
snowwrestler 12y ago
I don't use Java because I'm more of a tea drinker.
deleted 12y ago
[deleted]
azatris 12y ago
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.

comex 12y ago

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

bradfitz 12y ago
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 12y ago
  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.