- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 31 May 2012 12:48:15 +0300
- To: James Graham <jgraham@opera.com>
- Cc: "Linss, Peter" <peter.linss@hp.com>, "<public-test-infra@w3.org>" <public-test-infra@w3.org>
On Wed, May 30, 2012 at 8:46 PM, James Graham <jgraham@opera.com> wrote: > I don't think we want a build step. In our ideal scenario, we clone the > repository, create a local branch with any patches we need to get things > working in our test setup, and then update the testsuite with a simple > fetch/rebase (plus whatever work is needed on our end to add any new tests). > Everything that requires a QA to set up a build environment and mess around > getting the output files from the build into a local repository that's not > just a clone of the upstream is an impediment to keeping the tests up to > date. We have a lot of experience with testsuites that are hard to update, > and it all suggests that the probability of someone doing the update falls > dramatically as the complexity of the operation increases. Mozilla imports testharness.js tests in a similar fashion -- clone the source repo, copy any files indicated in the manifests, and that's it. (We don't have a way to maintain local patches, since testharnessreport.js serves our need well enough.) So at least for testharness.js tests, I also don't think we need a separate build step.
Received on Thursday, 31 May 2012 09:49:08 UTC