[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

--- Comment #4 from Jonathan Bedard <jbedard at apple.com> ---
(In reply to Lauro Moura from comment #2)
> (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?

Changing toKey to include version is probably something we want to do for non-mac ports (or maybe even GTK ports specifically) rather than everywhere, because we attempt to collapse major MacOS/iOS versions into a single group (although it gets weird because we want to consider the mid-year release a major release, which is why we have the whole "xxxE" thing going on)

We also definitely want https://bugs.webkit.org/show_bug.cgi?id=214511, because machine with different kernel versions would be considered different configurations still.

-- 
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/20200722/9ff1a3b5/attachment-0001.htm>