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-de...@lists.alioth.debian.org > > christian.ehrha...@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
signature.asc
Description: This is a digitally signed message part
