From: Frank Rowand <[email protected]>
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.
Patch 1 changes the Specification version to "2-rc" to indicate
that following patches are not yet accepted into a final version 2.
Patch 2 is an example of a simple change to the Specification. The
change does not change the content of the Specification, but updates
a formatting directive as suggested by the Documentation maintainer.
I intend to take some specific suggestions from the August 2021
discussion to create stand-alone RFC patches to the Specification
instead of adding them as additional patches in this series. The
intent is to focus discussion on a single area of the Specification
in each patch email thread.
[1] https://lore.kernel.org/r/CA+GJov6tdjvY9x12JsJT14qn6c7NViJxqaJk+r-K1YJzPggFDQ@mail.gmail.com
[2] https://lore.kernel.org/r/[email protected]
Frank Rowand (2):
Documentation: dev-tools: KTAP spec change version to 2-rc
Documentation: dev-tools: use literal block instead of code-block
Documentation/dev-tools/ktap.rst | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
--
Frank Rowand <[email protected]>
On Thu, Mar 17, 2022 at 4:26 AM <[email protected]> wrote:
>
> From: Frank Rowand <[email protected]>
>
> 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.
>
> Patch 2 is an example of a simple change to the Specification. The
> change does not change the content of the Specification, but updates
> a formatting directive as suggested by the Documentation maintainer.
Thanks -- personally, I'd rather this change _does_ go in straight
away, even before the 2-rc renaming.
> I intend to take some specific suggestions from the August 2021
> discussion to create stand-alone RFC patches to the Specification
> instead of adding them as additional patches in this series. The
> intent is to focus discussion on a single area of the Specification
> in each patch email thread.
Seems like a sensible way to structure the discussion. It could get a
little bit messy if there end up being merge conflicts, but the whole
thing could be collapsed into a single patchset later if that ended up
making more sense. (Though that might remove the need for the "rc"
version, depending on exactly when and how it happened.)
I'd also be curious to see patches to tests and/or test parsers to
show off any particularly compatibility-breaking and/or interesting
changes, though I don't think that _has_ to be a prerequisite for
discussion or the spec.
>
> [1] https://lore.kernel.org/r/CA+GJov6tdjvY9x12JsJT14qn6c7NViJxqaJk+r-K1YJzPggFDQ@mail.gmail.com
> [2] https://lore.kernel.org/r/[email protected]
>
> Frank Rowand (2):
> Documentation: dev-tools: KTAP spec change version to 2-rc
> Documentation: dev-tools: use literal block instead of code-block
>
> Documentation/dev-tools/ktap.rst | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> --
> Frank Rowand <[email protected]>
>
Cheers,
-- David
On 3/17/22 03:42, David Gow wrote:
> On Thu, Mar 17, 2022 at 4:26 AM <[email protected]> wrote:
>>
>> From: Frank Rowand <[email protected]>
>>
>> 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?
>
>>
>> Patch 2 is an example of a simple change to the Specification. The
>> change does not change the content of the Specification, but updates
>> a formatting directive as suggested by the Documentation maintainer.
>
> Thanks -- personally, I'd rather this change _does_ go in straight
> away, even before the 2-rc renaming.
>
>> I intend to take some specific suggestions from the August 2021
>> discussion to create stand-alone RFC patches to the Specification
>> instead of adding them as additional patches in this series. The
>> intent is to focus discussion on a single area of the Specification
>> in each patch email thread.
>
> Seems like a sensible way to structure the discussion. It could get a
> little bit messy if there end up being merge conflicts, but the whole
> thing could be collapsed into a single patchset later if that ended up
> making more sense. (Though that might remove the need for the "rc"
> version, depending on exactly when and how it happened.)
Yes, if I host a branch then no need for the preliminary rc version.
>
> I'd also be curious to see patches to tests and/or test parsers to
> show off any particularly compatibility-breaking and/or interesting
> changes, though I don't think that _has_ to be a prerequisite for
> discussion or the spec.
That is a good suggestion.
-Frank
>
>>
>> [1] https://lore.kernel.org/r/CA+GJov6tdjvY9x12JsJT14qn6c7NViJxqaJk+r-K1YJzPggFDQ@mail.gmail.com
>> [2] https://lore.kernel.org/r/[email protected]
>>
>> Frank Rowand (2):
>> Documentation: dev-tools: KTAP spec change version to 2-rc
>> Documentation: dev-tools: use literal block instead of code-block
>>
>> Documentation/dev-tools/ktap.rst | 20 +++++++++-----------
>> 1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> --
>> Frank Rowand <[email protected]>
>>
>
> Cheers,
> -- David
On Sat, Apr 23, 2022 at 7:16 AM Frank Rowand <[email protected]> wrote:
>
> On 3/17/22 03:42, David Gow wrote:
> > On Thu, Mar 17, 2022 at 4:26 AM <[email protected]> wrote:
> >>
> >> From: Frank Rowand <[email protected]>
> >>
> >> 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