[Webkit-unassigned] [Bug 214087] webkitdbpy: Partial loading of results from configurations with same version_name but different version

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=214087

Lauro Moura <lmoura at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dpino at igalia.com

--- Comment #2 from Lauro Moura <lmoura at igalia.com> ---
(In reply to Jonathan Bedard from comment #1)
> I'm not super familiar with how we should be thinking about GTK
> configuration differences, so it's certainly possible we need a special UI
> case for GTK.
> 
> I think there is also a lack of standardization among the GTK bots, though.
> https://results.webkit.org/api/suites?platform=GTK may shed more light on
> the issue. Looks like we're running 4.19, 5.4 and 5.5. Is that correct?
> 

Yeah, as it happens to get the version from the platform, in this case, the Linux kernel of the host. We are in the process of standardizing the workers as much as possible but I'm not sure if we'll be able to use the same kernel for all workers.

> What's going on here is that I've assumed that version_name and version are
> related (because they are on Apple's platform, ie, Catalina refers to
> 10.15.*). That may not be true for other ports. It would just be a UI change
> to expose the version number in GTK configurations.

For GTK, nowadays version name is used to distinguish the Xvfb and Wayland results when uploading, and version is kinda "ignored", but soon we'll be enabling the GTK4 bots so this probably will need more thought.

As you said, this causes both Xvfb configurations to have the same key, writing to the same slot in the resultsByKey object in timeline.js and thus "filtering" the results.

There would be any problem to change the toKey behavior to include the version?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200717/c3cd9f07/attachment.htm>