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