4 ms·

I think he's been banned from the issue tracker.

by mig39 4y ago

joshuamorton 4y ago
Possibly, but he was actively participating in https://github.com/golang/go/issues/44577 https://github.com/golang/go/issues/44577 up until the week it was fixed. If that's the root of the issue though, most of the article ("no one will get promoted for prioritizing that at Google.", "the go team has not prioritized it", etc.) is wrong. They may not have addressed the issue in the precise way he wanted, but I also think it's rather unreasonable to expect someone to not only address your issue, but address it in the precise way you suggest. That's rarely globally optimal and feels rather entitled.
- 8organicbits 4y ago
  I think the problem with the proposed solution (https://github.com/golang/go/issues/44577#issuecomment-857200479 https://github.com/golang/go/issues/44577#issuecomment-85720...) is that the refresh is used to keep the cache from getting too stale. Would it be reasonable for golang modules on sourcehub to be served from a stale cache? The problem is that the refresh does a full clone which is too heavyweight. The other user who accepted that proposed fix had a single module that had a single user, so they can tolerate some weird caching behavior for their toy project.
  - joshuamorton 4y ago
    If I'm reading correctly, it would not be stale, but be directly proxied, which would mean that a popular module could result in a higher overall qps (but this is also true if people clone directly from sourcehut). On the other hand, Drew's suggestion would actually result in stale caches. There comes a point (and it isn't a particularly far-off point) where disabling this would result in significantly increased traffic to sourcehut. That's a problem, but it's a problem with sourcehut's scalability.
    - 8organicbits 4y ago
      > This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches. They mention that requests still are served from the cache when refresh is disabled.
- cycomanic 4y ago
  So the solution is that everyone who does not want that behavior should request that they turn of refresh traffic for their domain? How long would it take until they would complain about people spamming their issue tracker if everyone who self-hosts a go module would start requesting this? Maybe they should request 500 times a day because that's what the proxy is doing.
  - joshuamorton 4y ago
    > How long would it take until they would complain about people spamming their issue tracker if everyone who self-hosts a go module would start requesting this? This same question comes up for ~any CI service or any number of other services that regularly build from source. There's a reason that github maintains a cache and that repo clones are served from that instead of by invoking the git command on the server. A git hosting service that can't handle a trivial clone qps isn't actually a git hosting service.
    - cycomanic 4y ago
      The guy who had 4G of traffic a day was self-hosting his go-module where he was the only user. Google downloaded his repo 500 times a day, that's some serious traffic for a single person, and no he was not a git hosting service. Also traffic is not free, so even if they maintain a cache somewhere there is a cost to this.
      - joshuamorton 4y ago
        > The guy who had 4G of traffic a day was self-hosting his go-module where he was the only user. Google downloaded his repo 500 times a day, that's some serious traffic for a single person, and no he was not a git hosting service. Ok so let me answer your previous question more explicitly: > So the solution is that everyone who does not want that behavior should request that they turn of refresh traffic for their domain? Yes. > How long would it take until they would complain about people spamming their issue tracker if everyone who self-hosts a go module would start requesting this? We have an answer to this. It is, empirically, a very long time, as there seem to be a handful (possibly only 2, certainly less than 5) users impacted negatively enough to report an issue. It does not usually make sense to solve an issue that doesn't exist. Presumably dozens of users reporting the same issue would cause a reprioritization, but if no one is complaining, there's no reason to change priorities.

I think he's been banned from the issue tracker.

by mig39 4y ago

I think he's been banned from the issue tracker.

Possibly, but he was actively participating in https://github.com/golang/go/issues/44577 https://github.com/golang/go/issues/44577 up until the week it was fixed. If that's the root of the issue though, most of the article ("no one will get promoted for prioritizing that at Google.", "the go team has not prioritized it", etc.) is wrong. They may not have addressed the issue in the precise way he wanted, but I also think it's rather unreasonable to expect someone to not only address your issue, but address it in the precise way you suggest. That's rarely globally optimal and feels rather entitled.

8organicbits 4y ago
I think the problem with the proposed solution (https://github.com/golang/go/issues/44577#issuecomment-857200479 https://github.com/golang/go/issues/44577#issuecomment-85720...) is that the refresh is used to keep the cache from getting too stale. Would it be reasonable for golang modules on sourcehub to be served from a stale cache? The problem is that the refresh does a full clone which is too heavyweight. The other user who accepted that proposed fix had a single module that had a single user, so they can tolerate some weird caching behavior for their toy project.
- joshuamorton 4y ago
  If I'm reading correctly, it would not be stale, but be directly proxied, which would mean that a popular module could result in a higher overall qps (but this is also true if people clone directly from sourcehut). On the other hand, Drew's suggestion would actually result in stale caches. There comes a point (and it isn't a particularly far-off point) where disabling this would result in significantly increased traffic to sourcehut. That's a problem, but it's a problem with sourcehut's scalability.
  - 8organicbits 4y ago
    > This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches. They mention that requests still are served from the cache when refresh is disabled.
cycomanic 4y ago
So the solution is that everyone who does not want that behavior should request that they turn of refresh traffic for their domain? How long would it take until they would complain about people spamming their issue tracker if everyone who self-hosts a go module would start requesting this? Maybe they should request 500 times a day because that's what the proxy is doing.
- joshuamorton 4y ago
  > How long would it take until they would complain about people spamming their issue tracker if everyone who self-hosts a go module would start requesting this? This same question comes up for ~any CI service or any number of other services that regularly build from source. There's a reason that github maintains a cache and that repo clones are served from that instead of by invoking the git command on the server. A git hosting service that can't handle a trivial clone qps isn't actually a git hosting service.
  - cycomanic 4y ago
    The guy who had 4G of traffic a day was self-hosting his go-module where he was the only user. Google downloaded his repo 500 times a day, that's some serious traffic for a single person, and no he was not a git hosting service. Also traffic is not free, so even if they maintain a cache somewhere there is a cost to this.
    - joshuamorton 4y ago
      > The guy who had 4G of traffic a day was self-hosting his go-module where he was the only user. Google downloaded his repo 500 times a day, that's some serious traffic for a single person, and no he was not a git hosting service. Ok so let me answer your previous question more explicitly: > So the solution is that everyone who does not want that behavior should request that they turn of refresh traffic for their domain? Yes. > How long would it take until they would complain about people spamming their issue tracker if everyone who self-hosts a go module would start requesting this? We have an answer to this. It is, empirically, a very long time, as there seem to be a handful (possibly only 2, certainly less than 5) users impacted negatively enough to report an issue. It does not usually make sense to solve an issue that doesn't exist. Presumably dozens of users reporting the same issue would cause a reprioritization, but if no one is complaining, there's no reason to change priorities.