3 ms·

An article that mentions a timeframe of “the next few hours”, but doesn't have any timestamp besides a date without a timezone.

reubenmorais 8y ago
You can hover the date to see the full timestamp, it's 2019-05-04 07:01:35 UTC-7.
- teej 8y ago
  Not available on all clients, notably mobile.
- TeMPOraL 8y ago
  It's an annoying UX antipattern, the only thing worse being not adding the on-hover text at all. Displaying date and time should be the default. HN has this problem too.
sachdevap 8y ago
Actually, if I'm not mistaken, the complete timestamp is available when you hover over the date.
teej 8y ago
Poor communication with zero accountability. A few hours could be 2, it could be 12. “I (name the individual accountable) will give you an update at 12:00 PT (name a time) as an update to this post (name the communication channel) with the current status and latest information on this issue (don’t promise time to resolution, just time to info).” Simple, clear, concrete, and unambiguous. I had hoped that Firefox had better communication procedures in the event of global-impact P1 issues.
derefr 8y ago
If Mozilla Studies are implemented the way other "push" update systems are, then probably your browser has an ID that it hashes to get a bucket ID that it builds into a URL to check for updates, plus a cron time offset for running those checks. Then, the experiments are rolled out by walking up the bucket ID list and gradually adding the addon to said buckets. Usually, this mechanism is explained as being helpful to ensure a rollout of an experimental update can be rolled back if it's failing. That's not so much a concern in this case, I think. But this mechanism has another effect: it works as a solution to the thundering-herd problem. Every browser updating at once is bad, not just for Mozilla's servers, but for every piece of Internet infrastructure that those browsers (and their arbitrary set of addons) talk to when they update/restart. Within the time budget you have for running a rolling update, you ideally want as few machines updating concurrently as possible, just because you don't want to generate mysterious correlated traffic bursts that make NOCs paranoid.
- SlowRobotAhead 8y ago
  We’ve always called this Canary Updates. You go a bit in, wait to see if the canary, then go further.

reubenmorais 8y ago

You can hover the date to see the full timestamp, it's 2019-05-04 07:01:35 UTC-7.

teej 8y ago
Not available on all clients, notably mobile.
TeMPOraL 8y ago
It's an annoying UX antipattern, the only thing worse being not adding the on-hover text at all. Displaying date and time should be the default. HN has this problem too.

sachdevap 8y ago

Actually, if I'm not mistaken, the complete timestamp is available when you hover over the date.

teej 8y ago

Poor communication with zero accountability. A few hours could be 2, it could be 12. “I (name the individual accountable) will give you an update at 12:00 PT (name a time) as an update to this post (name the communication channel) with the current status and latest information on this issue (don’t promise time to resolution, just time to info).” Simple, clear, concrete, and unambiguous. I had hoped that Firefox had better communication procedures in the event of global-impact P1 issues.

derefr 8y ago

If Mozilla Studies are implemented the way other "push" update systems are, then probably your browser has an ID that it hashes to get a bucket ID that it builds into a URL to check for updates, plus a cron time offset for running those checks. Then, the experiments are rolled out by walking up the bucket ID list and gradually adding the addon to said buckets. Usually, this mechanism is explained as being helpful to ensure a rollout of an experimental update can be rolled back if it's failing. That's not so much a concern in this case, I think. But this mechanism has another effect: it works as a solution to the thundering-herd problem. Every browser updating at once is bad, not just for Mozilla's servers, but for every piece of Internet infrastructure that those browsers (and their arbitrary set of addons) talk to when they update/restart. Within the time budget you have for running a rolling update, you ideally want as few machines updating concurrently as possible, just because you don't want to generate mysterious correlated traffic bursts that make NOCs paranoid.

SlowRobotAhead 8y ago
We’ve always called this Canary Updates. You go a bit in, wait to see if the canary, then go further.