From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Subject: [dpdk-dev] Minutes of Technical Board Meeting 2021-06-02
Date: Fri, 16 Jul 2021 07:51:49 -0700 [thread overview]
Message-ID: <20210716075149.034dce20@hermes.local> (raw)
Minutes of Technical Board Meeting, 2021-06-02
==============================================
NOTE: The technical board meetings every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC.
Meetings are public, and DPDK community members are welcome to attend.
NOTE: Next meeting will be on Wednesday 2021-06-09 @3pm UTC, and will be
chaired by Thomas.
1/ CI infrastructure
--------------------
The current CI infrastructure is failing. The root cause appears to be
the upgrade by UNH IOL causing test failures. The test failures impact the
patch approval process since patches marked as failing CI are normally not
allowed.
Proposal was to have another set of resources to test upgrade before
deploying.
2/ ABI stability period
-----------------------
When initially discussed the stability period was going to be two
years, but in final compromise a trial period of one year was agreed
to but the wording in documentation allows for longer periods.
In the documentation (guides/contributing/abi_policy.rst)
"Major ABI versions are declared no more frequently than yearly"
The proposal is to go to two year period but there are some open
concerns that need addressing:
- several data structures and inline functions need to be hidden
to reduce the exposed ABI.
- many experimental features need to be moved to stable status.
- deprecated functions and fields need to be removed.
If 21.11 is going to have two year ABI window, then cleanups are
needed.
Related discussions:
Should the scope of Long Term Stable (LTS) be expended? Right now,
the scope is limited to bug fixes. Vendors and distro's using LTS
would appreciate having new drivers (and PCI ids).
What about backporting standalone new libraries to LTS?
Conclusion: is that more discussion about requirements and risks
are needed before expanding LTS.
Indirect results of the current ABI policy has benefits. The ABI clamp
has acted to reduce wild/unstable changes and causes better designs.
Downside is that there is less of a trial window for changes, if a new
feature requires ABI change it goes into the yearly release without getting
longer period of review and testing.
What kind of upcoming features need ABI breakage?
Conclusion:
Taskforce will be setup to make a more concrete recommendation.
The taskforce will give status update in 2 weeks (next TAB)
and recommend action for 21.11 in one month.
reply other threads:[~2021-07-16 14:51 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=20210716075149.034dce20@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@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).