Re: Unifying testsuite policy and getting rid of CSS exceptions

On 14/09/17 19:23, Geoffrey Sneddon wrote:
> The question is where we go from here, and there are three sides to this.
> 
> 1. What we do with existing tests:
> 
> a. We keep them where they are now.
> 
> b. We move all CSS WG spec test suites into css/.
> 
> c. We move all CSS WG spec test suites to the top-level.
> 
> 
> 1. Do we remove the versioning from future CSS WG test suites:
> 
> a. Yes.
> 
> b. No.
> 
> 
> 2. Where do new test suites go:
> 
> a. At the top level.
> 
> b. In css/.
> 
> c. Up to the editor of the individual spec.
> 
> 
> 3. Do we move existing tests to match the above?
> 
> a. Yes.
> 
> b. No.
> 
> 
> 4. Where do we run the extra CSS lints:
> 
> a. Only in css/.
> 
> b. In all directories containing tests for CSS WG specs.
> 
> 
> As far as I'm aware, the status-quo is 1a, 2a, 3b, 4a. The CSS WG's
> preference is 1b, 2b, 3c, and I assume 4b (given without it the CSS
> WG's tooling is likely to get pretty broken pretty fast).

Well, I screwed up here.

The survey meant to end up as:

1. Do we put new test suites for CSS WG specs in versioned directories:

a. Yes

b. No


2. Where do new test suites for CSS WG specs go:

a. At the top level

b. In css/

c. Either at the top level or in css/, with no preference between either
except for being consistently in one

d. Up to the editor of the individual spec as to whether they want to
use the CSS WG tooling


3. Do we move existing tests to match the above:

a. Yes

b. No


4. Where do we run the extra CSS-only lints:

a. Only in css/

b. In all directories containing tests for CSS WG specs

c. Nowhere (and almost certainly break the CSS WG's tooling)


And the CSS WG's preference is 1: b, 2: b, 3: a, 4: a/b (they're
identical given previous answers).

I believe the preference of the WPT admins is 1: b, 2: a, 3: a, 4: c
(this is essentially "remove all special-casing for CSS testsuites").

/g

Received on Thursday, 14 September 2017 23:47:11 UTC