W3C home > Mailing lists > Public > public-test-infra@w3.org > January to March 2013

Re: Syncing upstream changes in testsuites

From: Tobie Langel <tobie@w3.org>
Date: Thu, 21 Mar 2013 16:54:23 +0100
To: James Graham <jgraham@opera.com>
Cc: Robin Berjon <robin@w3.org>, Dirk Pranke <dpranke@chromium.org>, public-test-infra <public-test-infra@w3.org>
Message-ID: <9FD6533821B34EFCB2E6C25E8E27940F@w3.org>
On Thursday, March 21, 2013 at 4:36 PM, James Graham wrote:
> On Thu, 21 Mar 2013, Robin Berjon wrote:
> > > Assuming that implementors actually want to import and run the tests,
> > > there are a number of practical issues that they face. The first is
> > > simply that they must sync the external repository with the one in which
> > > they keep their tests. That's pretty trivial if you run git and pretty
> > > much a headache if you don't. So for most vendors at the moment it's a
> > > headache.
> > 
> > Just a silly thought, I may be missing something, but does that sync really 
> > need to use git? I mean presumably it's a read-only sync that only needs to 
> > happen once a day or so (it's not a big deal if runs are 24h behind the repo 
> > I would think). In that case, if git is an issue, one can just grab and 
> > unpack:
> > 
> > https://github.com/w3c/web-platform-tests/archive/master.zip
> That works iff you don't have any local patches to the testsuite. That 
> typically won't be the case, almost certainly for testharnessreport.js 
> which is explicitly intended to be patched, but potentially also for other 
> files (doubly so if you have a single web-platform-tests repository that 
> contains both the upstream tests and local tests you have written but not 
> yet submitted to W3C). The operation you want to run to sync the tests is 
> a lot more like "git pull --rebase" than "delete and reclone".

We need to understand what implementor's requirements are here.

Received on Thursday, 21 March 2013 15:54:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:08 UTC