From: Aaron Conole <aconole@redhat.com>
To: techboard@dpdk.org, dev@dpdk.org
Subject: Minutes of Technical Board Meeting, 2023-05-31
Date: Wed, 04 Oct 2023 11:11:14 -0400 [thread overview]
Message-ID: <f7t8r8ih17x.fsf@redhat.com> (raw)
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
reply other threads:[~2023-10-04 15:11 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=f7t8r8ih17x.fsf@redhat.com \
--to=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=techboard@dpdk.org \
/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).