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 > >> 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? > > 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) 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. 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. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
