On 31 March 2015 at 14:36, Matthias Klose <[email protected]> wrote: > Does your testing goes beyond docker.io? If no, I would claim your testing is > dubious at best ;) There are certainly still issues, but to me it starts to > look usable. There are other dubious things like how golang-gotools is built > in > Debian ...
I apologise for how harsh my tone here was -- re-reading, it was way more coarse than it should've been; I was frustrated at the time of writing and too much of that came out in my response. I did test beyond Docker (several other Go projects, and all directly via the Go toolchain "go get", "go build", etc); I don't have lots of extra time especially since gccgo isn't involved in my day-to-day work. Generally, I'm concerned that gccgo claims to be language-compatible but not necessarily toolchain-compatible (compiler flags come to mind, since that's what the Docker build system ended up needing changes to build under gccgo). Separate from that, it concerns me a great deal that Docker's integration tests fail (and the daemon itself segfaults) when I compile it via gccgo. I'm not saying this is necessarily representative, but it's an important point to consider IMO, since I don't think it's going to be the only package that has runtime issues when compiled with a completely different buildchain. > I appreciate the testing you do, and I'm interested to see gccgo specific bug > reports, if these are reproducible with Go 1.4.2. And yes, I would appreciate > a > golang-gotools built from the 1.4 branch in experimental too (golang is > outdated > in experimental, so I updated myself to 1.4.2 and uploaded a package to the > Launchpad PPA ~doko/toolchain). We did push Go 1.4.1 to experimental in Jan, but I'll try to find some cycles to get 1.4.2 up there too; thanks for the prod. I'll see if I can get the IBM Docker folks to do some testing on their side, too. Last I asked, they couldn't reproduce failures with a gccgo-built daemon, but I'll see if they've specifically run upstream's test-integration-cli suite against it (since that's the workload that gets me a segfaulting daemon within just a few tests). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
