Minutes of Technical Board Meeting, 2023-05-31

Minutes of Technical Board Meeting, 2023-05-31

[Aaron Conole]

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