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/[email protected] [2] https://inbox.dpdk.org/dev/1981390.eGJsNajkDb@thomas/
