Re: [RFC PATCH 0/2] Documentation: dev-tools: begin KTAP spec v2 process
From: David Gow
Date: Sat Apr 23 2022 - 03:53:37 EST
On Sat, Apr 23, 2022 at 7:16 AM Frank Rowand <frowand.list@xxxxxxxxx> wrote:
>
> On 3/17/22 03:42, David Gow wrote:
> > On Thu, Mar 17, 2022 at 4:26 AM <frowand.list@xxxxxxxxx> wrote:
> >>
> >> From: Frank Rowand <frank.rowand@xxxxxxxx>
> >>
> >> 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:
smime.p7s
Description: S/MIME Cryptographic Signature