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