[ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye

[Luca Boccassi]

Control: clone -1 -2
Control: retitle -2 transition: dpdk
Control: reassign -2 release.debian.org
Control: affects -2 -1

On Fri, 2020-11-13 at 13:47 +0100, Thomas Goirand wrote:
> On 11/12/20 5:09 PM, Luca Boccassi wrote:
> > Source: openvswitch
> > Version: 2.13.0+dfsg1-12
> > Severity: normal
> > X-Debbugs-CC: pkg-dpdk-devel at lists.alioth.debian.org christian.ehrhardt at canonical.com
> > Tags: bullseye
> > 
> > Dear Openvswitch Maintainers,
> > 
> > We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible,
> > we'd really like to go to bullseye with the latest upstream LTS, as
> > 19.11 is EOL at the end of next year.
> > 
> > OVS support for DPDK 20.11 will be released upstream in v2.15, which is
> > due for release on February 15 [1].
> > Bullseye transition freeze is on January 12 [2], so the dates
> > don't align very well.
> > 
> > So we are looking to formulate a plan that you can agree with, to sort
> > this out.
> > 
> > Based on experience, what Ubuntu usually does to meet release deadlines
> > is to upload from git earlier than the release, so that all major
> > incompatibilities can be sorted. And then after the freeze, once the
> > release is officially out, do a final upgrade to the released version -
> > since a similar enough version was uploaded from git, and at the end of
> > a release cycle it's mostly bug fixes that land upstream, such an
> > upload is acceptable.
> > 
> > So we'd like to propose the following ideas:
> > 
> > - between now and December: upload v2.14, to minimize the later jump
> > - by the first week of January: upload 2.15~git from the tip of the
> > master branch to experimental
> > - stabilize and sort eventual build issues
> > - upload dpdk 20.11 and ovs 2.15~git to unstable
> > - upload 2.15 proper in February as a bug fix upload to unstable
> > 
> > What do you think? Does this sound like a workable plan?
> > 
> > We are of course happy to help - Ubuntu will go through the exact same
> > process for 21.04, so a lot of the work is "shared".
> > 
> > Thank you!
> 
> Hi Luca,
> 
> I wouldn't mind going for this kind of plan, however, I would really not
> like uploading a version which isn't final from the upstream point of
> view. So we would have to get the release team approve for a late upload
> of OVS 2.15. Note that I'm really not happy with the current state of
> OVS in Buster, which isn't usable right now (I've been using the tip of
> the git branch for 2.10.0 in production, not what's in Buster that often
> crashes). I don't want this to happen again.
> 
> Please get the release team in the loop, therefore, and make them
> pre-approve such a plan, by opening a bug with them.

Ok, cloned to notify the team.

I proposed an earlier upload from git as a temporary measure to ease
the ABI transition. I worry that an ABI transition 2 months after the
transition freeze is too much to ask, even if it only affects
src:openvswitch (and src:collectd, but that's a straightforward
rebuild, no changes needed).
Nonetheless, let's see if the release team considers this acceptable.

> Also, I would very much like to have OVS and OVN being packaged and
> maintained on both Ubuntu and Debian the same way. I would very much
> like if this could happen, because maintaining OVS is hard, and I really
> feel alone doing it. Your thoughts?
> 
> Cheers,
> 
> Thomas Goirand (zigo)

I'm sure this could be arranged - after all we already follow the same
model for src:dpdk, where myself and Christian share the workload and
use a common repository for Debian and Ubuntu.

Christian, would it be possible for you to initiate a discussion with
the relevant people from the Ubuntu side?

-- 
Kind regards,
Luca Boccassi