Re: Proposal to refactor the CSS test repo

On Apr 24, 2014, at 12:00 PM, Tobie Langel <tobie.langel@gmail.com> wrote:

> 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?

It hasn't been an issue with the support files, but those are relatively static. Anyway, as I said to Rebecca, I'm not actually proposing copies of the tests, I'm just pointing out that the tooling would be fine with, since they have to deal with it for support files already.

> 
>> 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. 

Not sure what you're talking about here, a custom format of what? symlinks?