RE: [Bugtracking] Scope of domconftest

> -----Original Message-----
> From: Dimitris Dimitriadis [mailto:dimitris.dimitriadis@improve.se]
> Sent: Thursday, June 28, 2001 2:11 PM
> To: 'www-dom-ts@w3.org'
> Subject: [Bugtracking] Scope of domconftest
> 
> 
> In order to speed up the process, I propose the following 
> (much in line with
> what was previously proposed):
> 
> 1. Submissions of tests are done using the 
> www-dom-ts-sumbission@w3.org
> mailing list

OK.  Would you expect big contributions (like the initial NIST load)
to be provided as a .zip or .tar.gz file with many test entries.

> 2. The tests are checked for correctness, validity and so 
> forth, as they
> will be viewable on the W3C CVS. Control is done by the DOM 
> TS moderators
> (as per the DOM TS process doc)

Basically, I think that a test should be committed to 
the CVS as soon as it 
passes the initial sanity check.  Committing a test to the 
CVS doesn't imply endorsement that the
test is a "good" test just that it doesn't break the build
and people can run it to make value judgements.

The inclusion of a test into a suite definition would 
signify an acceptance of the test as a "good" test.

> 3. Tests that are not ready to form part of a suite and need work, are
> checked into the SF CVS and we work on them in the domconftest project

I think it would be rare that more than one person would be 
try to collaborate on improving one test.  If the W3C CVS is the test
repository, having a secondary repository is distracting.

If someone wants to improve or fix a test, they can 
checkout the W3C CVS, work on their local copy, and email the diff
make to the submissions list and then Dimitris can update the W3C CVS
with the patch.  (Assuming Dimitris is the only one with commit
access to the W3C CVS).  

If the SourceForge CVS is used or the W3C CVS can be 
opened up a bit, then Dimitris doesn't have
to be involved in every modification and I think the
initial development would go much faster.

Can we subscribe to the submissions list?

> 4. Once finalized, the test goes back to the W3C machinery, 
> where it joins
> the rest of the tests and makes up a test suite.

> 5. Documentation, compression, generation of code and so 
> forth can be done
> in either case and in tierh place, we just need to take a decision.

The Ant build file should file should automate the process, so anyone
can recreate the entire distribution by checking out the source
from the CVS.

> 
> (If I've forgotten something, please add to the list)
> 
> I think we should spend as little time as possible on this 
> matter to start
> working. I realise we need to decide on where development 
> will take place,
> but I also point out that SF was primarily thought of as a 
> bug tracking
> system. Mwe should spend some postings on this topic to reach 
> a conclusion?
> 
> /Dimitris
>

Received on Thursday, 28 June 2001 15:41:27 UTC