W3C home > Mailing lists > Public > public-css-testsuite@w3.org > April 2014

Proposal to refactor the CSS test repo

From: Rebecca Hauck <rhauck@adobe.com>
Date: Wed, 23 Apr 2014 16:57:21 +0000
To: Peter Linss <peter.linss@hp.com>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <CF7D692D.4DD37%rhauck@adobe.com>
Hi Peter & All

Peter, I believe you and I spoke about this some time ago at TPAC and I'd like to resurrect the discussion here.

As you know, the current directory structure & naming (/approved +  /contributors/company/submitted) were part of a legacy system and don't have much meaning or usefulness now.  In fact, if one were looking just at the names here, they'd assume that all tests in approved were actually approved and those in submitted were not. As the process, infrastructure, and the tests themselves have evolved, we now have lots of stuff on both of those directories where that'd be a false assumption.  Beyond that, it's not that easy to browse the repo and find all the tests for a given spec because they're split across approved/submitted and across contributors directories.  I know Shepherd provides a nice interface to see this, but since this is all code, the directories where the code is stored should be organized in a way that it's easy to find stuff, like most/all other codebases.  I also believe we should keep a tests 'status' out of the directory naming entirely, especially since we're moving to the 'everything that's merged is approved' github model and since we have Shepherd for the pre-github stuff.

I propose refactor the directories to use the spec short names just as the spec repo does.

The current root of the repo looks like this:

approved/[spec-shortname, spec-shortname...]
contributors/[company/testarea, company/testarea...]
cvs-import/[legacy or unfilled stuff?]
test-plans/[spec-shortname, spec-shortname...]

The proposed new structure:

tests/[spec-shortname, spec-shortname...]
test-plans/[spec-shortname, spec-shortname...]

I'm guessing what's in cvs-import can be folded in and I'm not sure what build-test is for, so you'll have to speak to that.

Assuming there aren't objections to this proposal that can't be overcome or addressed, I'd like to start the discussion the work that needs to be done for this in scripts, Shepherd, etc. I can offer some cycles to help with this and I'd invite anyone else who wants to help.

Also in full disclosure, I'm proposing this now as a precursor to another proposal I'd like to make to get the CSS repo more integrated (as a submodule) of the WPT repo.  Since that is an entirely different different discussion, I'll reserve that for a different thread/list, but I think getting our stuff well organized must come first.

I welcome feedback from anyone on this list and look to Peter for guidance on the best way to proceed.

Received on Wednesday, 23 April 2014 16:57:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:20 UTC