[ovs-dev] OVS needs to release new stable versions.
mmichels at redhat.com
Tue Jun 30 13:08:22 UTC 2020
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
>> 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 ,
>> and some consequences like creating new implementations of key servers
>> (keys.openpgp.org) with some design changes in compare with SKS.
>>  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).
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
>> 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