On Sat, Apr 23, 2022 at 7:16 AM Frank Rowand frowand.list@gmail.com wrote:
On 3/17/22 03:42, David Gow wrote:
On Thu, Mar 17, 2022 at 4:26 AM frowand.list@gmail.com wrote:
From: Frank Rowand frank.rowand@sony.com
An August 2021 RFC patch [1] to create the KTAP Specification resulted in some discussion of possible items to add to the specification. The conversation ended without completing the document.
Progress resumed with a December 2021 RFC patch [2] to add a KTAP Specification file (Version 1) to the Linux kernel. Many of the suggestions from the August 2021 discussion were not included in Version 1. This patch series is intended to revisit some of the suggestions from the August 2021 discussion.
Thanks for kicking this off again. There were definitely a lot of good ideas in those threads which we haven't got to yet.
I think there is an interesting line to walk between keeping KTAP sufficiently "TAP-like" (particularly w/r/t being able to reuse existing TAP parsers), and actually adding features, but I don't recall seeing many such issues in the previous threads.
Patch 1 changes the Specification version to "2-rc" to indicate that following patches are not yet accepted into a final version 2.
I'm okay with this, though I'd want us to be a little careful with the timing so we don't end up with, for example, 5.18 having a KTAP spec called 2-rc which is functionally indistinguishable from v1.
I finally have some time to return to this.
I could host a branch on my kernel.org "frowand" linux kernel. When agreement is reached on a patch on this mail list, I would add it to the branch. When the discussion determines that it is time to release a version 2 of the specification I would add one more commit that only updates the version.
Does that sound like a good way to proceed?
Yeah: that sounds good to me.
-- David