From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DE2C8A0A02 for ; Fri, 26 Mar 2021 08:54:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B6D244067B; Fri, 26 Mar 2021 08:54:57 +0100 (CET) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by mails.dpdk.org (Postfix) with ESMTP id 63AAB4067B for ; Fri, 26 Mar 2021 08:54:56 +0100 (CET) Received: from mail-qt1-f199.google.com ([209.85.160.199]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lPhJ2-0005q2-0Q for stable@dpdk.org; Fri, 26 Mar 2021 07:54:56 +0000 Received: by mail-qt1-f199.google.com with SMTP id l63so4755389qtd.23 for ; Fri, 26 Mar 2021 00:54:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Gv7m5ULyruYuoGiLzwizSpS7BAY9WEw9UnwowJv3nO4=; b=ZDheaGjp3y+gSBibghYsS8lGNMdCuSwT/pFIj5W0AFLIIlhC3kiPe9841kU9kIek7T oMfeXIK/c/Ld/09H6PyOC4Ww/+MePUc7UIzC7ElqaLLbrPXSjlJKosn0Iufl1KcEgHXg axymRjnTn9kq/tpF7AV6BL3B82pVbF57R13ehSFCtUqxU+Glzr9zmETn6bkyQMUNXcM8 q93LkN+vYJWvIaF2k4woNORomKisDrskOa/PIOJ4zM6cOT1DdbvdgnI1OL/B/Uc7wzEq Y0pYbzWIcLHoedsUcQxuoX1tKNZEM8xLklVbFxWjn3xAuHPhQSmFRvO2WNLOmNCKbeCq tMvg== X-Gm-Message-State: AOAM5326Ley3QgnD7DLcYh55Su3hHPoUokOJRbss1UNVsuQOxZX9h3p7 l2gsV51RoTjZ9rBRAr0LR0qiAcLjmd1nwkz87sTi3nd/wRrWpDviydWoI/s0U5MSSh8zQZ8+WQQ YLIY62sRfsVySogmAajRaqvWenWOZeZbEIE+rfcki X-Received: by 2002:a05:620a:16dc:: with SMTP id a28mr11758657qkn.442.1616745294944; Fri, 26 Mar 2021 00:54:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJGiU+ZAL4kUtjAiFaSCY+j3HjPqQIxO6pLXQRXV/RLtmUfn7/0yvNtYxSdQLKYGbBMjV3YCPuEFRrUFi+2Bw= X-Received: by 2002:a05:620a:16dc:: with SMTP id a28mr11758648qkn.442.1616745294616; Fri, 26 Mar 2021 00:54:54 -0700 (PDT) MIME-Version: 1.0 From: Christian Ehrhardt Date: Fri, 26 Mar 2021 08:54:28 +0100 Message-ID: To: John McNamara Cc: Luca Boccassi , dpdk stable Content-Type: text/plain; charset="UTF-8" Subject: [dpdk-stable] DPDK LTS Release Build-Testing miss - let us try to improve X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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