Attendees:
- Aaron
- Bruce
- David
- Ferruh
- Jerin
- Kevin
- Konstantin
- Maxime
- Nathan
- Patrick
- Stephen
- Tyler
Minutes:
- Bruce will be moderator on June 14, 2023
- Call for additional items
- Userspace Dublin
- CFP - Ready to go.
- Awaiting on final TB review, feedback received from
Kevin, Thomas
- Virtual Speakers
- Do we exclude or include? Reality is we will need to include
- In-person is always the most desirable, we can't exclude virtual
speakers
- Quality of Virtual experience needs to improve
Any feedback to the LF team re: virtual experience
- Form review from Evi with Nathan
- Submit all the changes
- Review process is open for the entire board, to be sent out by
Nathan.
- Nathan to send out an invite for Thu, July 6
- Submit expenses ASAP
- LF hires
- Ben Thomas to solicit feedback from others and building more
content to promote project
- Feel free to reach out and help Ben with this effort
- David Young starts on June 12
- Discuss on how to align the next LTS release for
- From https://mails.dpdk.org/archives/dev/2023-May/269411.html
- YAGNI vs reserved fields with init()
- Discussion with Jerin, should we follow YAGNI which will need
to use next-abi.
- Testing concerns with next-abi. Needs even more CI runs to ensure
proper coverage
- More time, and additional matrix functions
- Adding checks for reserved fields as a key.
- Checks are needed for the old code + new library case
- Reserved fields also cause bad behavior w.r.t. development
- Reserved fields also take up space that may never be needed
- General discussions about ABIs
- Thomas prefers the two versions approach (current, next)
- Have a single define and just removing it should work.
- NEXT abi is "cleaner" in some cases
- NEXT ABI is probably the best approach and we will try it out when
going forward on a case-by-case basis
- What it takes to Extend the API breaking release more than a
year as first step.
- Cannot discuss today, but we need to discuss the period of
compatibility that we currently support
- Maybe it can be extended based on some other approach
- Discuss how to better share tree maintenance work for the main
libraries.
- new maintainers?
- Need for more maintainers in the libraries / examples, not enough
reviewers, etc.
- Reach out to existing maintainers for additional subtree splitting
- Always depends on the library, and some have plenty of coverage
- Maybe also doing some restructuring of the libraries
- new tree maintainers
- lack of faster merging because there aren't enough tree
maintainers
- Create more subtrees?
- Creates a more maintainership burden
- Next step to start looking at what to split, who to do the work,
etc. Needs more discussions, though.
(Didn't get to...)
- Thomas requests people read email on Power management brainstorm
