Image reports - default value for start/end build number and tests

Bug #1198195 reported by Fathi Boudra on 2013-07-05
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LAVA Dashboard (deprecated)
Fix Released
High
Stevan Radaković

Bug Description

I'm confused by the default value used for start build number/end build number/tests on the filters section available on image reports. It seems to keep the value selected "previously".

As a result, I should always edit the end build number value and the tests (if new tests have been added).

I expect the following default value:
- end build number is always the latest (you'll have to edit only if you want to check specific range of builds)
- start build number is the latest build number - 15 or 20 (a range of the last 15-20 builds seems reasonable)
- all tests are selected (you'll have to edit only if you want to filter some tests)

Obviously, that's my personal preferences. If there's rationale to current behavior, I'll be glad to hear them.

Related branches

Changed in lava-dashboard:
assignee: nobody → Stevan Radaković (stevanr)
status: New → Triaged
importance: Undecided → Medium
Alan Bennett (akbennett) wrote :

I encountered this issue today looking at the kernel ci builds. Ideally, people will go here every day and determine whether or not a kernel that was booting, no longer boots. With both the Graph and the Data table hiding data, it simply looks like there was no build. (unless someone thinks of looking at the end-number).

Changed in lava-dashboard:
importance: Medium → High
Fathi Boudra (fboudra) on 2013-08-12
Changed in lava-dashboard:
milestone: none → 2013.08
Changed in lava-dashboard:
status: Triaged → In Progress
Stevan Radaković (stevanr) wrote :

Wrt selected tests, we include default behavior to be only those that have latest builds, and remember any other user selection.
So if you change selected tests once, thet selection will be remembered for next time you visit the page.
The main reason for this is that there are some reports that have very large amount of tests where some of which are outdated and not necessary; the other reason being it was the part of QA TL wishlist during design.

Regarding start and end build, I concur.

On 13 August 2013 15:26, Stevan Radaković <email address hidden> wrote:
> Wrt selected tests, we include default behavior to be only those that have latest builds, and remember any other user selection.
> So if you change selected tests once, thet selection will be remembered for next time you visit the page.
> The main reason for this is that there are some reports that have very large amount of tests where some of which are outdated and not necessary; the other reason being it was the part of QA TL wishlist during design.

To resolve the use case "large amount of outdated tests", filters
should be used properly:
test case filtering feature, a filter can be limited to test runs with
particular values for particular attributes.

Wrt the 2nd reason, I haven't been involved in the design hence I
can't comment on Miloswz's wishlist.

It seems to me that the page has still a usability issue if we keep
current behavior.

Milosz Wasilewski (mwasilew) wrote :

My 3 cents:
 - I also don't like the start/end works currently. End should always default to latest available job. If someone wishes to preserve start/end settings, these should be passed using GET parameters
 - The default selection was my idea and I'm quite happy how it works. The reason, as Stevan mentioned, is the fact that historical results (no longer used) sometimes make the table too big). Ideal solution would be to show all tests that were present in the latest job description, not only the ones that produced some results.

Milosz Wasilewski (mwasilew) wrote :

On 14 August 2013 12:08, Fathi Boudra <email address hidden> wrote:
> To resolve the use case "large amount of outdated tests", filters
> should be used properly:
> test case filtering feature, a filter can be limited to test runs with
> particular values for particular attributes.

This way you won't see any new test cases that might be added after
the filter was defined. The filter can be updated when new tests come,
but this creates another bottleneck and IMO doesn't solve the
usability problem.

Changed in lava-dashboard:
status: In Progress → Fix Committed
Fathi Boudra (fboudra) on 2013-09-05
Changed in lava-dashboard:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers