Re: Proposal to refactor the CSS test repo

On Apr 24, 2014, at 20:40, Peter Linss <peter.linss@hp.com> wrote:


On Apr 24, 2014, at 10:56 AM, Rebecca Hauck <rhauck@adobe.com> wrote:



  From: Peter Linss <peter.linss@hp.com>
Date: Wednesday, April 23, 2014 at 4:47 PM
To: Rebecca Hauck <rhauck@adobe.com>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>, Elika
Etemad <fantasai@inkedblade.net>
Subject: Re: Proposal to refactor the CSS test repo


 On Apr 23, 2014, at 9:57 AM, Rebecca Hauck <rhauck@adobe.com> wrote:

 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…]
build-test/[???]
contributors/[company/testarea, company/testarea…]
cvs-import/[legacy or unfilled stuff?]
test-plans/[spec-shortname, spec-shortname…]
tools

 The proposed new structure:

 tests/[spec-shortname, spec-shortname…]
test-plans/[spec-shortname, spec-shortname…]
tools


 I have no issue with this plan, but do note than many tests are linked to
more than one spec and I expect that to get more common as specs evolve. So
while we can adopt a simple convention, like put the test in the directory
for the first linked spec, people will have to be aware that the files
under a single directory are not the exhaustive list of the tests for that
spec. Gathering and copying all the tests for a single spec into a single
package is what the build scripts do.


 Yes, I’d planned on going with the first spec link for the actually copy,
but Tobie’s suggestion for using symlinks may work well for this scenario.
AFAIK, github treats symlinks just as the file system does. Of course that
means that if the original file is deleted, the onus is on the deleter to
remove the symlink or they’ll be left dangling.  This is a minor issue that
can be automated though.   What are the implications of this approach on
the build scripts and Shepherd?


Symlinks would just appear to be additional copies of the files, both
Shepherd and the build scripts already deal with that just fine (although I
have to verify how mercurial's internal APIs treat them for some of
Shepherd's code). For that matter, making copies of the tests rather than
symlinks would also be fine with the tools, for example, we already do that
with most of the support files.


Isn't that somewhat of a maintenance nightmare?

Both mercurial and git handle symlinks, so long as the hg-git tool deals
with them that should be ok, my main concern with symlinks is that I don't
believe either mercurial or git handle them properly on Windows systems...

I'm also concerned with the general usability issues with symlinks, I'm not
sure most test developers will understand, and deal with all the
consequences of working with linked files.


The other option is creating a custom format akin to what's already being
done with the .headers files.

--tobie