On 6/30/20 12:57 AM, 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 was mistaken, 2.11.4 has not been released yet, so we only need to tag 2.11.3. I created the v2.11.3 tag, signed it and pushed to repository. And now it is available on the "Releases" tab on github. > >>> 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. For me 2.13 looks good. But, I guess, the easiest way to decide is to create a patch and discuss it on a dev mailing list. I'll send one. > >>> 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). > >> 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. > > Yes. > >>>> 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. > OK. So, in this case point 3 of my proposed plan is on me. :) Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
