Re: [RFC PATCH 0/2] Documentation: dev-tools: begin KTAP spec v2 process

From: David Gow <davidgow@google.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Kees Cook <keescook@chromium.org>,
	"Bird, Tim" <Tim.Bird@sony.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	Rae Moar <rmr167@gmail.com>,
	Guillaume Tucker <guillaume.tucker@collabora.com>,
	Daniel Latypov <dlatypov@google.com>,
	kernelci@groups.io,
	KUnit Development <kunit-dev@googlegroups.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/2] Documentation: dev-tools: begin KTAP spec v2 process
Date: Sat, 23 Apr 2022 15:53:17 +0800	[thread overview]
Message-ID: <CABVgOSm5Bc13o5UEVEiRCpzrq1Jqt11DjQ7YWPyjfj_6fBwWVw@mail.gmail.com> (raw)
In-Reply-To: <37465a0f-7deb-bedb-1a84-90324f554ad1@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

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

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]