Re: Proposal to refactor the CSS test repo

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


On Apr 23, 2014, at 3:36 PM, Tobie Langel <tobie.langel@gmail.com> wrote:

On Wed, Apr 23, 2014 at 6:57 PM, Rebecca Hauck <rhauck@adobe.com> wrote:

[...]

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

This is a great move. Thanks for driving this.

[...]

> The proposed new structure:
>
> tests/[spec-shortname, spec-shortname…]
> test-plans/[spec-shortname, spec-shortname…]
> tools

May I suggest instead to adopt the same format already used in the WPT
repository, with shortnames at the root (eventually containing a test plan
within each directory).


I'm fine with that, we just need a convention for identifying things that
aren't tests, references, and support files, like test plans (either file
naming or directory naming) so the tooling can ignore them.


Yes. There are such conventions in place already. I'm not sure they're
properly documented however. Folks on @public-test-infra would know.

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

Suggest you'd bring that up on public-test-infra@ asap.

All tooling built around WPT assumes specs are at the root of the
directory, using their shortnames. So including the CSS repo as a submodule
won't help you much here, unless you fix both open-source tools AND lobby
implementors to fix theirs (WPT is well on track to be part of most if not
all browser vendors CI environments in the near future).


Seems like an odd limitation if it can't handle one additional level of
directory. Even if the CSS tests were to be merged with the WPT repo given
the number of CSS specs it would seem to be useful the have them all under
a "css" directory.


Software tends to have odd limitations. :-(

Why not simply merge with the WPT repo? What technical issues prevent this?


Again, losing years of issue tracking, build tools, testing infrastructure
to get specs out of CR, etc... This has all be discussed before, do we
really need to have this discussion again? There is a plan to sync our
issue tracking tools with GitHub's, but it's not done yet.


Sorry. Given the drastic changes being made, I wasn't expecting much of the
pre-existing tracking and infra to hold up. I also misread Rebecca's
proposal as implying a full move to Git.

Finally, I thought that getting these tests run within vendors CI systems
would trump issue-archiving. I guess it doesn't. :-/

--tobie