Minutes of Techboard Meeting 2026-03-18

[Bruce Richardson <bruce.richardson@intel.com>]

Members Attending
=================

Aaron Conole
Bruce Richardson
Hemant Agrawal
Jerin Jacob
Kevin Traynor
Konstantin Ananyev
Morten Brørup
Thomas Monjalon

NOTE
====
The technical board meetings are on every second Wednesday at 3 pm UTC.
Meetings are public. DPDK community members are welcome to attend on Zoom:
https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?password=d808f1f6-0a28-4165-929e-5a5bcae7efeb

Minutes of previous meetings: http://core.dpdk.org/techboard/minutes

Items Covered
=============

1. Discussed the schedule for the upcoming DPDK Summit in Stockholm in May
   - Thomas proposed a draft schedule for the two days based on accepted
     talks.
   - Feedback was provided by techboard leading to a few adjustments:
      - TB liked grouping similar talks and themes together
      - Made adjustments so that lightning talks were better grouped and
        placed more towards end of sessions rather than being scattered.
   - Thomas to check with authors for decision on one final pair of talks
     and then forward suggested agenda to LF conference organisers.

2. Handling of security reports
   - There are only two people from Tech board currently assigned to the
     security list to handle security reports.
   - When reports come in, there can be some effort involved in
     communicating expectations and timelines with reporters.
   - Need for more people to be involved in managing this
   - As reports come in, domain experts will be pulled in as necessary.

3. Question on updates to release notes for already-completed releases.
   - Discussion triggered by submitted patch for release note addition for
     25.11 [1]
   - Consensus was that adding new items to release notes is fine
       - Agreed that the additions should really have some small mention
         e.g. in brackets after addition title, indicating the date at
         which the addition was made
       - This could cover case where a late test report comes in using
         other components, such as firmware, which may not have been
         available at time of original release.
   - Any release note changes should be CC'ed to stable for backporting to
     the relevant release branches.
   - Although not relevant yet, some brainstorming done on how to handle
     changes/deletions from released docs:
       - One discussed suggestion was to use strike-out text for removed
         text to make the (dated) removal clearly visible.
       - No decision made, as none necessary, at this point.

4. Discussion on l2fwd-jobstats example and role of examples vs apps
   - Referred to techboard following some discussion of l2fwd-jobstats on
     mailing list [2]
   - jobstats example has characteristics of a stress or performance test,
     not just that of a reference example on how to use an API
   - It was discussed whether or not it could be converted to a test or
     moved to the app folder, but no clear decision reached as most call
     participants were not very familiar with the example
   - Consensus was that, in general, the code in "examples" should be kept
     simple, and should be for the purpose of demonstrating how to use
     libraries and APIs
     - Benchmarking code should be in unit tests or in apps in the "app"
       folder.
     - Biggest exception to this right now is l3fwd, however it cannot be
       moved without breaking lots automated CI and similar systems that
       use it. Little benfit from moving.
   - Bruce to follow-up more on jobstats example, gain more background and
     info on it.

5. Project "wishlist" validation process
   - At a joint techboard-governing board meeting last year, the proposal
     was made to start tracking a "wishlist" for new features in DPDK, to
     encourage a longer-term, more ambitious roadmap for the project.
   - Thomas has now created a new "Product" in the DPDK bugzilla called
     "Wishes" against which feature requests can be raised. This allows
     people to submit feature ideas to the project
   - The Techboard then has the role to review and approve (or reject as
     unsuitable) these suggestions.
   - Consensus was that this new approach was definitely worth trying to
     see how it works out.
     - One request from Kevin, accepted by the board, was that the
       description of new requests should, by default, come populated with 
       a suitable skeleton, or template, description to help guide anyone
       submitting ideas.

6. Maintaining a list of begineer tasks for those new to DPDK
   - The milestone field in DPDK bugzilla is currently unused, so Thomas
     has added a "Beginner Task" milestone there.
   - This allows maintainers, or others doing bug triage, to identify and
     tag bugs which are not serious and yet also relatively easy to fix.
   - This should provide an easy "on-ramp" for those who want to start
     contributing to the project.
     - It was noted that since this is in main DPDK bugzilla, it also can
       be used for DTS issues, providing an easy on-ramp there too.
   - Suggestion was made that this milestone should be added to the new
     "wishes" bugzilla product too, to potentially identify easy new
     feature requests as well as bugs.


[1] https://inbox.dpdk.org/dev/20260317155538.1282864-1-rileyf@linux.ibm.com
[2] https://inbox.dpdk.org/dev/1981390.eGJsNajkDb@thomas/