Bug 1886810 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

My feeling is we should allow `user` lifetimes in addition to `ping`, but gated via a warn.

While we typically work with distributions in the _add them together_ style, `user` lifetime represents "current state" and while I think there is some danger in folks getting confused, that strikes me as a perfectly valid way to look at data. It may be unnecessary and slightly lossy though, so a warn is justified.

`Application` lifetime should be completely disallowed. It's almost certainly going to induce double counting to some degree, for no benefit. Consider the case where the application is open starting at say, 11PM on a Monday, and remains so until Wednesday morning at 8AM. This spans two metrics ping sends. The first Metrics ping has data from 11PM to 4AM the following day. The second Metrics ping has that data, too, plus itself, such that if you add the two together, you double count data from the first day. Backing this is out would be sufficiently complex as to be practically impossible.

We should encourage folks who have a demonstrated need to have a different schedule for distribution collections than the Metrics ping to use a `ping` lifetime on a custom ping.
My feeling is we should allow `user` lifetimes in addition to `ping`, but gated via a warn.

While we typically work with distributions in the _add them together_ style, `user` lifetime represents "current state" and while I think there is some danger in folks getting confused, that strikes me as a perfectly valid way to look at data. It may be unnecessary and slightly lossy though, so a warn is justified.

I agree that `Application` lifetime should be completely disallowed. It's almost certainly going to induce double counting to some degree, for no benefit. Let's consider a concrete case where the application is open starting at say, 11PM on a Monday, and remains so until Wednesday morning at 8AM. This spans two metrics ping sends. The first Metrics ping has data from 11PM to 4AM the following day. The second Metrics ping has that data, too, plus itself, such that if you add the two together, you double count data from the first day. Backing this is out would be sufficiently complex as to be practically impossible.

We should encourage folks who have a demonstrated need to have a different schedule for distribution collections than the Metrics ping to use a `ping` lifetime on a custom ping.

Back to Bug 1886810 Comment 1