3 ms·

> They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why

> They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tracker in violation of their own CoC does not seem like good faith behavior either. Note that the message from 'FiloSottile does not clearly spell out whether DeVault's ban was following a CoC, it just obliquely quotes some nasty stuff that he's apparently said in the past. I think other commenters are correct to call it irrelevant, it's about as relevant as it would be if I started randomly quoting Rob Pike's notorious comments about syntax highlighting [1]. Overall, I totally acknowledge the Golang team is providing a workaround that will solve the (admittedly abrasively spoken) user's problems. What I'm saying is that that is not enough. If you want an open language that will not turn into .NET, you have to do better by your community and also be transparent as to how and when you're planning to solve your users' problems. And preferably also be transparent about CoC bans, especially if there is a technical discussion involved. For example, this sounds like a reasonable response to me: "We have written up a task to make our proxy code parse robots.txt correctly, but there are N other tasks above it, and it looks like we won't be able to work on it for approximately the next six months. Until then, a workaround is..." ---------------------------------------- [1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ1RDiio8J https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ....

tptacek 4y ago
This is how every issue tracker works. It takes time to explain things (and more time to generate all the facts needed to put together an accurate explanation). What matters is that they got him a workaround --- apparently, almost immediately. He hasn't taken them up on it; it's unclear why. There's no indication I can see that DeVault's "banning" from the issue tracker has anything to do with any of this. There's always going to be some standard the Go team (or the Rust team, or the Clojure team, or the Scala team, or any other team down the line until you just decide to do your own language and hope for the day you get to occupy the gratifying job of fielding these kinds of tickets) doesn't meet, for someone on some message board somewhere.
- deleted 4y ago
  [deleted]
- voxtech 4y ago
  This claim is outrageous- if disabling sourcehut is a valid workaround, then google should end the refresh behavior on the proxy since it isn't providing any valuable service. If the proxy provides a valuable service, then disabling sourcehut would degrade service for sourcehut users.
  - tptacek 4y ago
    That logic doesn't even cohere. If Github and Gitlab can sustain more aggressive queries from the module proxy, they may have fresher cache entries in that proxy. That's what being more capable gets you. The Go team isn't obligated to operate at the lowest common denominator of all source hosts. If the Go team's workaround was to make sr.ht not viable for Go modules, that would be deeply problematic. But it isn't; in fact, nobody who's upset about this seems to be able to describe what the Go team's workaround would even impact. Can you?

tptacek 4y ago

This is how every issue tracker works. It takes time to explain things (and more time to generate all the facts needed to put together an accurate explanation). What matters is that they got him a workaround --- apparently, almost immediately. He hasn't taken them up on it; it's unclear why. There's no indication I can see that DeVault's "banning" from the issue tracker has anything to do with any of this. There's always going to be some standard the Go team (or the Rust team, or the Clojure team, or the Scala team, or any other team down the line until you just decide to do your own language and hope for the day you get to occupy the gratifying job of fielding these kinds of tickets) doesn't meet, for someone on some message board somewhere.

deleted 4y ago
[deleted]
voxtech 4y ago
This claim is outrageous- if disabling sourcehut is a valid workaround, then google should end the refresh behavior on the proxy since it isn't providing any valuable service. If the proxy provides a valuable service, then disabling sourcehut would degrade service for sourcehut users.
- tptacek 4y ago
  That logic doesn't even cohere. If Github and Gitlab can sustain more aggressive queries from the module proxy, they may have fresher cache entries in that proxy. That's what being more capable gets you. The Go team isn't obligated to operate at the lowest common denominator of all source hosts. If the Go team's workaround was to make sr.ht not viable for Go modules, that would be deeply problematic. But it isn't; in fact, nobody who's upset about this seems to be able to describe what the Go team's workaround would even impact. Can you?