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... _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
