Usability issues with status-history

[William Reade]

On Sun, Mar 20, 2016 at 2:51 AM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> +1 on collapsing repeats. I'd also prefer to add more data to status so
> that we can collapse entries, rather than dropping data so that we
> don't/can't see it in history.
>
> What do we base "sensible filtering" on? Exact match on message isn't
> enough for download messages, obviously, and I'd be very hesitant to bake
> in any knowledge of specific message formats.
>

Yeah, message formats would be a pretty poor basis for similarity.

IIANM, our status entries can carry additional data which we don't render.
> If we add the concept of overarching operations to status entries (e.g.
> each "image download progress" entry is part of the "image download"
> operation), then we could collapse all adjacent entries within that
> operation. This could be a simple string in the status data; or we could
> extend the status schema. Either way.
>

YANM :). I'm pretty sure that adding a value to status data is the easiest
approach; and, given that we can't change all the code at once, I think
it's also better to have the maybe-present value explicitly in the
status-data-bag rather than part of the schema (and hence subtly implied to
be more reliable than it actually is). Thoughts?

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160320/c54ccef7/attachment.html>