On 11/13/20 11:46 PM, Thomas Goirand wrote: > On 11/13/20 6:54 PM, Ilya Maximets wrote: >> On 11/13/20 1:47 PM, 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, >> >> Hi, Luca and Thomas. >> >>>> >>>> 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. >> >> >From the upstream OVS perspective feature freeze usually happens on >> January 15. After this point only bug fixes (under normal conditions) >> could be accepted. Unfortunately, as it always happens, last few days >> before the feature freeze might be hot in terms of accepting big number >> of new features. We could try adjusting these dates if January 12 is >> a critical hard deadline, so the feature-list will be stable to the date. >> Let me now if you need this kind of measures from the upstream OVS. >> We can discuss. >> >>>> >>>> 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. >>> >>> 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? >> >> I'm not very familiar with debian/ubuntu packaging process for OVS and OVN, >> but if there is something that we can do from the upstream side to help, e.g. >> by accepting some patches or streamlining release processes, let me know. >> We clearly have a communication gap between upstream OVS and maintainers of >> packages in distributions. >> >> Best regards, Ilya Maximets. > > Hi Ilya, > > Thanks for getting involved in the discussion. > > What I'm worried, is if somehow, the latest OVS breaks OpenStack > Victoria, which will be the OpenStack release for Bullseye. Can you > assure me that it wont break it?
I don't think that we have any destructive/incompatible changes planned. Also, IIRC, upstream OpenStack CI had a job to test with OVS master branch (I need to recheck that). So, I hope that we could catch issues early, if any. Best regards, Ilya Maximets.
