patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
To: John McNamara <john.mcnamara@intel.com>
Cc: Luca Boccassi <bluca@debian.org>, dpdk stable <stable@dpdk.org>
Subject: [dpdk-stable] DPDK LTS Release Build-Testing miss - let us try to improve
Date: Fri, 26 Mar 2021 08:54:28 +0100	[thread overview]
Message-ID: <CAATJJ0K003k8OUz=ka8EAVsyCf-Hz_n8Vyf+9kfG505FeL9vzw@mail.gmail.com> (raw)

Hi John,
I still owe you a summary of how the recent issue we discussed in the
Release meeting yesterday and how it could be catched better in the
future .

#1 The Issue (skipping over most technical details intentionally)
There were linking changes that crept into DPDK 19.11.x and various
companies (including myself) have tested their software against it
successfully which led to the release of 19.11.[67] as they are. But
later on it was found that rebuilding the dpdk-consuming software (in
this case OpenVswitch) no longer works with the new releases - and
thereby we have broken software that depends on us in stable releases.

#2 Solution - rebuild DPDK depending SW as part of the verification process
The Tests that are done for the verification of DPDK stable releases
should not only cover "running software against it" but also
"(re-)bulding software against it. Here we have a slight issue, as in
the current example newer openvswitch 2.14.x and 2.15.x work fine with
the new and the old code. But OVS 2.13.x which is their LTS stream and
the one that timewise came together with 19.11 is the one that breaks.

#3 Better Solution - rebuild (also old) DPDK depending SW as part of
the verification process
We should not only ask to "(re-)build the SW against the new DPDK" but
also to "(re-)build the SW level that matches the given DPDK release".
In this particular case for e.g. DPDK 19.11.x releases we'd always
expect to also have OVS 2.13 to be tried against it. In a similar
fashion DPDK 20.11 will always have to be tested vs OVS 2.15 even if
in a year there might be a newer OVS revision.

It would be great if you could sort that out with all associated
Test/Verification and Openvswitch peers that are involved with the
project. Once you feel that it was thoroughly cleared I would tag
19.11.8-rc1 as suggested by Thomas in the call. On that we can check
if the tests are done and also include a convincing amount of "and yes
my SW still rebuilds fine against the new release".

Thanks in advance!

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

                 reply	other threads:[~2021-03-26  7:54 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='CAATJJ0K003k8OUz=ka8EAVsyCf-Hz_n8Vyf+9kfG505FeL9vzw@mail.gmail.com' \
    --to=christian.ehrhardt@canonical.com \
    --cc=bluca@debian.org \
    --cc=john.mcnamara@intel.com \
    --cc=stable@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).