From: Patrick Robb <probb@iol.unh.edu>
To: dev <dev@dpdk.org>
Cc: ci@dpdk.org, Dean Marx <dmarx@iol.unh.edu>,
Paul Szczepanek <Paul.Szczepanek@arm.com>,
Luca Vizzarro <Luca.Vizzarro@arm.com>,
Andrew Bailey <abailey@iol.unh.edu>,
Thomas Wilks <thomas.wilks@arm.com>
Subject: DTS WG Meeting Minutes - July 31, 2025
Date: Tue, 12 Aug 2025 11:59:59 -0400 [thread overview]
Message-ID: <CAJvnSUBb_qSa0XetRw_C9cpPJZ+1DqWBOrvXHCZy=b4Mcxx0Gg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3541 bytes --]
####################################################################
July 31, 2025
Attendees
* Patrick Robb
* Luca Vizzarro
* Paul Szczepanek
* Andrew Bailey
####################################################################
Minutes
=====================================================================
General Discussion
* RFC deadline for 25.11 development is August 31.
=====================================================================
Patch discussions
* RSS:
* Updated and rebased. Ivan’s comments have been addressed.
* Patrick Robband Andrew Baileyto review this and test it on lab devices
(must include mellanox)
* dts: add file management
* Patrick Robbto review
* Provides abstraction which defines a file on TG, SUT, or DTS engine
system
* There are some stylistic differences between how testsuite docstrings are
written
* Currently, the only “rule” is that testsuite developers write “steps”
and “verify” section
* Steps and Verify should also have an empty line included between
them
* Otherwise, there are various discrepancies (example, ordered vs
unordered list for providing “steps”) and we need to provide more
comprehensive rules to bring the testsuite docstrings in alignment
* Also some missing “Attributes” or “Returns” sections for various class
and method docstrings
* There is major duplication between module, class, and method
docstrings in each testsuite.
* Module docstring should be a few sentences briefly identifying the
testsuite and the DPDK functionality validated in the testsuite
* Testsuite class can just be a stock phrase to satisfy the linter,
like “testsuite class”
* Testcase docstrings contain the actual details
* Thomas Wilks is looking through testsuites and looking for problems with
code style. We should provide a code style guide going forward.
* Example: Some functions which return None have no typehinted return,
when technically they should return None like “ -> None “
* Testcase naming convention
* The old requirement of prefixing testcases with “test_” is still
present in some testcases. Although it’s not a “problem” for testcases to
be named in this way, we should stop doing this going forward and do a 1
time re-naming of all the existing testcases that are named in this way.
* Docs builds:
* We have some private methods which are not actually made private (they
are not prefixed with an underscore), so these methods are showing up in
the testsuite docs unnecessarily.
* Patrick Robb and luca.vizzarro@arm.comreviewed change requested patches
* Confirmed all of those patches are tracked
* It may be better to not use the change requested status at all. Just
provide comments on series, and let the submitter change the series to
“superseded” when they send a new version.
=====================================================================
Bugzilla discussions
* Reviewed bugzilla tickets:
*
https://bugs.dpdk.org/buglist.cgi?quicksearch=component%3Adts&list_id=9444
=====================================================================
Any other business
* Andrew at UNH is looking at TG driver binding, which was previously
removed from DTS.
* Intel CI Docs build had a failure for some DTS docs on a patch applied to
next-dts
* Need to remove the autodoc pydantic dependency from the standard docs
build, which Luca is going to do
* Next meeting is Aug 14, 2025
[-- Attachment #2: Type: text/html, Size: 3785 bytes --]
reply other threads:[~2025-08-12 16:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJvnSUBb_qSa0XetRw_C9cpPJZ+1DqWBOrvXHCZy=b4Mcxx0Gg@mail.gmail.com' \
--to=probb@iol.unh.edu \
--cc=Luca.Vizzarro@arm.com \
--cc=Paul.Szczepanek@arm.com \
--cc=abailey@iol.unh.edu \
--cc=ci@dpdk.org \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=thomas.wilks@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).