Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Proposal to update TCK process text to explicitly allow test modification after a challenge
  • From: Scott Kurz <skurz@xxxxxxxxxx>
  • Date: Mon, 27 Jun 2022 00:49:17 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CWlwq+b6+L2YOFjDAqlDKQChpEma66ngSQt3eL5gZxY=; b=eSB8aBRIcFhobq0F75cyIX1iPQnKheWZwu2tLbV9mgvvEYGLrrjalfqEqqbUEsJqw1unarsOWiTf23uKNXfQUCvn1+tl8kBkW65eLbrNTkGRws87e6Omx3f6clTOdEbi81lUqK72rqj272fP2Y5GnrXPG8mq5LtsIZ2/qKKbKhaMSpwsqZt7g2ZgHhu8aCHlCnMVCjye12dYnaZoiE6+FJjHSt7RO5lJ+wZe4Pec4toLpVX9gq2BfvwgBSgDoJyjNa7nQOmX6r1eGhSA4S7YWVRsgN2JQwIX9HIXfbEmgbyMNt5McSWtNsW4la8oHNEmrSp0rmLSneVkZVDz8mJ2gQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Am+SrJ2lGGTIuIrTtdznFU0eJ9W/lw9k3ncyRWkEcUaFRrCu1Y6RNOhRlTUCoqRWAt40Z5jTiOBE47Apb9HOuuF0xaTHhjscjYr7if4GXoVdvs/utuvyKRc19QItbSf3Jeno8DOCXvVqhdbfQwAj//px8u5qoFNC3kI+LRf3oPgtk2j8GjIsk3MH8qnEXzZ8js049f43RQa5vHTbVRmVmeSWNUJaRBaB+cz/irMiiMKu8/jqhnk+SBjI8sTxQi64Z1/NfdmNJEYW1sHknfVefUPQW1BjKGbSgRTWfii+QDdwevafg7ZiWwEs+7RzpfI8TSJFhlJu9wB7kVyDmtOZBw==
  • Delivered-to:
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Thread-index: AdiJvj80pBmsE4m7T06QS7SMCdf2iw==
  • Thread-topic: Proposal to update TCK process text to explicitly allow test modification after a challenge

I’d like to propose adjusting the TCK process for a service release in response to a challenge.


In the recent Batch TCK v2.1.1 service release:

we addressed a challenge by modifying a test, and “loosening” the validation logic. 


Now, I think a straightforward reading of the TCK process

suggests this isn’t allowed… you can only exclude the test or workaround.


If it weren’t for Scott Marlow voicing his support for the idea,

I’d have assumed we couldn’t do this. 


The key point was ensuring that, with this modification, any implementation passing the old test should also pass the new, modified test.

Abstracting over the details…  instead of verifying that variable “a” was set to value “XYZ” we allowed for either “a” OR “b” to be set to value “XYZ”.


I am in favor of the change, since it allows us to avoid throwing away a useful test ( and we did go ahead and do the change and v2.1.1 release).


But I’m circling back here with this email, and this PR I drafted on the subject:


Scott Kurz

Back to the top