W3C home > Mailing lists > Public > public-test-infra@w3.org > April to June 2017

Re: Web Platform Tests Pull Request Commenting

From: Bob Holt <bob@bocoup.com>
Date: Thu, 18 May 2017 11:48:42 -0400
Message-ID: <CAFf+SkN5Y8svYEf4zmkxdd9NiF4gJQEq0H0-1fJ_RojvjjQ8cQ@mail.gmail.com>
To: James Graham <james@hoppipolla.co.uk>
Cc: public-test-infra@w3.org
Since my email yesterday, I've been working on the data model required to
do everything we would want in the PR dashboard (building on one James
began). I have added it to the bottom of the specification document
I will write up a text description explaining the reasoning behind the
entities and their relationships, but I will say that in looking at the
potential complexity here, it looks more and more like a standalone

On Thu, May 18, 2017 at 9:58 AM, James Graham <james@hoppipolla.co.uk>

> On 16/05/17 19:19, Jeff Carpenter wrote:
>> I certainly don't want to step on any toes here, but I wanted to throw
>> my opinion out there since I see possible opportunities for saving time
>> and effort. From my perspective it looks like the project I'm working
>> on, WPT Dashboard, and this project have very similar aims:
>> - WPT Results Consolidator: Collect and display WPT results
>> - WPT Dashboard: Run, collect and display WPT results
> So, I think that's a simplification of the situation.
> The stability dashboard will need to show multiple runs for a specific
> test. It will only need to deal with one PR's worth of tests vs the
> hundreds of thousands of tests in the entire repository, which vastly
> changes the kind of visualization options that are required. It will need
> to show additional information like where the PR is synced on w3c-test.org.
> It will need to draw attention to anything that blocks the PR from landing,
> but won't necessarily need features like search that are required to work
> with the full set of results.
> I definitely see the appeal of sharing code where it makes sense, but I
> wonder if in this case it won't be more effort to try and make one tool
> that does everything well vs two tools that do a specific thing well. I
> think I would need to see a concrete proposal for how we could build a
> single tool here to judge better whether the tradeoffs are worth it.
Received on Thursday, 18 May 2017 15:49:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:13 UTC