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.

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)

Reply via email to