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

Ben Pfaff blp at ovn.org
Tue Jun 30 15:01:07 UTC 2020


On Tue, Jun 30, 2020 at 09:08:22AM -0400, Mark Michelson wrote:
> On 6/29/20 6:57 PM, Ben Pfaff wrote:
> > 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.
> > 
> > Great.
> > 
> > > > 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
> > key).
> > 
> > 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).
> 
> I've released three versions of OVN so far, all making the commits manually.
> And so far, I've made a mistake 1 time out of the 3.
> 
> So yes, I'd say a script is a much better approach, and if Justin does have
> such a script, I'd love to have a copy of it :)
> 
> If that script is not shareable for some reason, then I'll just create my
> own, probably when it comes time to release OVN 20.06.1

Oh, I don't think there is a script--I think Justin always did it by
hand too.  But I think one should be created...


More information about the dev mailing list