DPDK patches and discussions
 help / color / mirror / Atom feed
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).