Re: CSS test repo refactored - branch ready for review

Hi Gérard,


>> All the locations of files within the repository are maintained by
>> people (you really don't want an automated process modifying the
>> repository).
>Forgive my question but ... where are *all of my submitted tests* now ?
>in my local repository? and in ?
>I ask this because ...
>There used to be a /contributors folder (which was in the /src/ folder)
>where all contributors had their folder by their username. Now, such
>/contributors folder is only visible, only accessible via mercurial and
>has only a few folders.
>I can see right now an
>but it is empty and this folder is not viewable, not accessible from

We are no longer keeping submitted tests in folders by user or company
name. We still have a place for work-in-progress that has user/company
folders under it, but this is really to support the legacy process when
people were pushing directly to Mercurial. Those files needed to be parked
somewhere and I chose the name 'work-in-progress' because it was more
descriptive than Œincomingı. We now no longer need special instructions or
specific directory names to submit a test. Itıs very simple - if youıre
submitting tests for the Backgrounds & Borders spec (for example), your
test goes in the css-backgrounds-3 directory. This makes it very easy to
find all of the tests for a given spec in one place rather than being
spread across multiple user/company folders.  It will also make it easier
for vendors to import tests for any given spec or set of specs (automated
or otherwise) as it eliminates the need to parse the test files to figure
out what specs theyıre testing. Implementors really want to access tests
by specs and not by who authored them (although we can rely on the
metadata for that if needed).

If you still have contributors folder locally, you likely have some hidden
dot files that prevented it from being removed when you updated your local
repo. It happened to me as well with those pesky .DS_Store files.  What
you see in the web interface at is accurate
and you can safely delete your local contributors folder.

And of course as you know, you can always query all of the tests you
authored via Shepherd or grep locally if you wish. Your tests were across
multiple specs so they got filed under the appropriate spec directories.
If you want the complete list of where everything went, the HG changeset
is here [1], but the Github interface actually gives you a little nicer
view of the the renaming [2]. Everything you had in
/contributors/gtalbot/incoming moved to /work-in-progress/gtalbot [3]. The
full description of the changes that were made are at the top of this
thread [4].

On somewhat of a side note, since weıre now in the Github world, any new
tests that land in the repo should start with a pull request where they
will be reviewed, approved, and merged from there. We are favoring this
over using the mailing list for test reviews for reasons I outlined here
[5]. All W3C test submissions are now done this way and itıs a much
cleaner approach than relying on an external system or directory naming
convention to reflect test status.  There are still a few who push
directly to Mercurial, but we are not broadcasting this workflow any
longer and and even the veterans are discouraged from doing this if what
theyıre submitting needs review. I personally only do so for housekeeping
tasks that donıt require a review. With this new workflow, all tests that
are merged into the repo can be assumed reviewed and approved.

Now, I realize that we still have many tests unreviewed from before we
adopted Github. We can still use Shepherd for tracking these-- either its
API or the web interface. However, at some point, weıll have to decide how
to reconcile these tests as itıs probably not realistic to expect that
thousands of tests will ever be reviewed by humans. Peter and I have had
some offline discussions about how to address this, but this is a issue to
solve later. We have Shepherd in the meantime (luckily). We wanted to make
these changes first to move closer to the way the rest of the W3C manages
tests. Weıre now in a better position to merge/move into the main W3C
web-platform-tests repo [6]. Thatıs also a separate discussion that only
just began at the last CSSWG F2F and it will certainly pick up again soon.
 We just had to do this part first.

Let me know if you have any other questions & thanks again for your
incredible attention to detail. :)



Received on Tuesday, 3 June 2014 01:42:06 UTC