[ovs-dev] OVS needs to release new stable versions.

Ben Pfaff blp at ovn.org
Mon Jun 29 22:57:32 UTC 2020

On Tue, Jun 30, 2020 at 12:43:48AM +0200, Ilya Maximets wrote:
> On 6/29/20 10:47 PM, Ben Pfaff wrote:
> > On Fri, Jun 26, 2020 at 12:18:37PM +0200, Ilya Maximets wrote:
> >> So, what is the proposed plan:
> >>
> >>   1. We should add missed git tags to 2.11.3 and 2.11.4 releases.
> >>
> >>      Ben could you, please, take care of this? (Alternatively, I could do that,
> >>      but I'm not sure what with the keys to sign tags and how this key
> >>      management handled these days since the collapse of web of trust.)
> > 
> > I think that it's probably best to take myself out off the critical path
> > here.  I started out using signed tags because they were easy for me,
> > since I already had a key in Debian's web of trust.  But I don't know of
> > a reason why they need to be signed, or signed by a particular key.  I
> > think it is perfectly reasonable if you push the tags, signed or
> > unsigned.
> OK.  I'll do that.


> > I don't know what you mean by "the collapse of the web of trust".  Did I
> > miss a memo?
> It was a reference to Certificate Spamming Attacks happened last year [1],
> and some consequences like creating new implementations of key servers
> (keys.openpgp.org) with some design changes in compare with SKS.
> [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

Oh my.  I did see something about that at the time, I think.  Ugh.

> >>   3. Prepare patches for OVS stable releases for all branches starting from
> >>      branch-2.5 and apply them.  Create, sign and push tags.
> >>
> >>      Ben, I know you handled this part last time.  What is the preferred way?
> >>      Someone else could prepare patches and send for review, I guess.
> > 
> > I think we should designate a newer "long term stable" release now that
> > OVN has released separately.
> Yeah.  That's a good point.  Maybe 2.13 is a good candidate for a new LTS?

I hope so?  I'd really rather not be in the middle of that decision.

> > That aside, I have never prepared separate patches for OVS stable
> > releases.  When I apply bug fixes, I backport them as far as necessary.
> > It would be a burden to figure this out retrospectively, but it's
> > usually easy at the time of bug fix.
> By "Prepare patches for OVS stable releases" I meant patches like this:
>    * 2ff0b7715 2019-09-06 | Prepare for 2.10.5.
>    * 5f19eaaf2 2019-09-06 | Set release date for 2.10.4. (tag: v2.10.4)

Oh!  Got it.  Justin used to do most of that work, so I didn't think
about it.  My part of the job was, typically, acking the patches and
pushing the tags (I did the latter because I was the one with the GPG

I suspect that a lot of it could be automated with a script (which would
probably be more reliable than doing it manually, which I *think* Justin
probably did).

> But yes, I agree that looking through patches and backport them selectively
> is too much work and will likely require even more people.  Backporting
> patches as far as necessary is a good practice. I do that too.

Wonderful!  I was sure hoping that there was not a big backlog of
patches that might need backporting, since it's much more difficult to
do it that way in my experience.

> We could do selective backports by request in case something missed, but
> we should not revisit all the patches while preparing stable releases on
> older branches. 


> >>   4. Update relevant docs outside of openvswitch main repository (web-site,
> >>      wiki, etc.)
> >>
> >>
> >> P.S.: We should, probably, do some periodic checks on released
> >> branches and make stable releases a bit more frequently.  For example,
> >> we could make regular stable release every few months in case we have
> >> fixes on top of the previous release.  I could keep monitoring things
> >> and ping people, but this might be better to have some plan, I think.
> > 
> > Yes, probably.  At one point Justin and I were definitely the people who
> > coordinated this, but now if it is left to us then it probably won't get
> > done, or not done often enough.
> > 
> > I really need some new people to take the leadership role here.
> > 
> I could take care of this.  I mean, I could periodically look at numbers
> of patches on stable branches and prepare minor releases if needed.

That would be fantastic.

More information about the dev mailing list