Re: Support files

On Oct 19, 2012, at 1:27 PM, James Graham wrote:

> 
> On Fri, 19 Oct 2012, Peter Linss wrote:
> 
>> On Oct 19, 2012, at 6:47 AM, James Graham wrote:
>> 
>>> It is mildly annoying that it's not clear what support files (video, audio, image, etc.) files exist, especially because of the current system where tests are copied around, so relative urls to files outside of a single submission are likely to break.
>>> 
>>> It would be nice to fix this in two ways:
>>> 
>>> 1) Create a repository like "support" that could be put at the top level, much like resources, allowing links like /support/images/pass.png to work.
>> 
>> While there are a bunch of commonly used support files, there are also a significant number of one-off support files used only by a single test. Putting those into a separate repository isn't exactly ideal either.
> 
> Sure, I'm not saying that all media files should be in a common repository. I'm saying that there should be one for a set of standard files that people can reuse between tests.

But then you have the issue of all users having to manage multiple repositories and understand what goes where. I guarantee novice users will get that wrong.

Especially as we have more community outreach programs like TTWF, the level of contributor's familiarity with VCS tools, let alone DVCS and multiple repositories, is going to be all over the map (and largely non-existent).  As an amusing data point, during the CSS WG's first TTWF event, we had over 400 commits to our test repository peaking at over 40 simultaneous branches, see:
http://hg.csswg.org/test/graph/c0f25b315d73?revcount=488
A great way to stress test your server, your tools, and definitely your users (people were having to pull and merge up to a dozen times before they could push).

I suggest that common support files simply live in a 'support' directory at the root of the repository and all references to them be relative. Anyone (or any tool) that moves them will be responsible for fixing up the relative paths. The w3ctestlib will have code for managing that process soon.

> 
>>> 2) Stop moving files around in repositories and track code review other than through position in the filesystem hierarchy.
>> 
>> Like Shepherd?
> 
> Perhaps. I haven't used it so it's hard to say. But in any case moving files around in the repo is badness.

That's a whole separate conversation that we've had before. As I've already said, the 'approved' directory in the CSS WG repository is a historical carryover from before we had Shepherd, each WG can lay out their repository as they see fit and moving files isn't necessary, but you may find utility in doing so. For example, we have all the TTWF contributors put their work under a common 'contributors/ttwf' directory. The quality of the work you get there varies widely and a staging area is helpful until the work has been reviewed and the contributor has a sense of what they're doing…

Received on Saturday, 20 October 2012 00:59:26 UTC