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

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).

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.

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.

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.