On 5/15/20 1:12 PM, Ihar Hrachyshka wrote:
On 5/15/20 12:24 PM, Numan Siddique wrote:
On Fri, May 15, 2020 at 8:23 PM Ihar Hrachyshka <[email protected]>
wrote:
On 5/11/20 10:15 AM, Ihar Hrachyshka wrote:
On 5/8/20 2:17 PM, Numan Siddique wrote:
On Fri, May 8, 2020 at 9:58 PM Ihar Hrachyshka <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
I would like the series to support multiple localnet ports per
switch
("routed provider networks for OpenStack") considered for
inclusion.
The series is here:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=173328
There's an updated (v3) version of 5/6 patch from the series
here:
https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/
(I'm not sure I posted it correctly - since other patches in the
series
didn't need any update from v2, I pushed only 5/6 but now it's
displayed
separately in patchwork; let me know if that's an issue and/or I
should
repost the whole series.)
I think it's better to repost as a whole series.
Thanks. Here is the full series (I also attached a cover letter):
https://patchwork.ozlabs.org/project/openvswitch/list/?series=176134
Note there's one issue in the new test cases that I am working on
right now and hope to fix a fix today. There will probably be v5 of
the series but I hope we can pick any other issues in the
implementation, reviews are welcome.
Hi all,
Bear with me since I am new to OVN release freeze process. Now that we
approach(ed?) hard freeze, I wonder if there's still a chance to include
the series mentioned above (there's v7 of the same up for review with
one ack), or it will have to slip into a next release. I understand that
not everything raised can - nor should - be included during soft freeze.
On the other hand, I haven't seen much of discussion as to merit of
inclusion of particular patches mentioned in this soft freeze thread.
Did the discussion happen anywhere else? In general, how does the
project decide on which exception requests to grant and which to shelve?
Hi Ihar,
Since your patches were submitted before the soft freeze deadline I think
they are definitely candidates to be included for 20.06.
Even if the branch-20.06 is created, we can backport your patches.
I see that you have received Ack from Dumitru for your series.
I applied the first 4 patches of your series to master just a while back.
I didn't get the chance to review your other 2 patches and I'm also
waiting
for Han if he has any comments for the other 2 patches.
Thanks!!!
BTW to clarify, I don't *complain* about the series not getting merged
(though I am glad if it does!), just trying to understand if there are
any other actions I should (have) take(n) to improve chances of timely
merge before branch cut-off. What I gather from your reply is 1)
inclusion or non-inclusion is case by case and up to individual core
contributors, there's no formal group decision; and 2) even after hard
freeze, feature patches *may* be backported.
Though re 2), on the other hand,
Documentation/internals/release-process.rst says about the branch
created on hard freeze: "Release branches are intended for testing and
stabilization. At this stage and in later stages, they should receive
only bug fixes, not new features."
Yes, ideally it would be very rare that we have to backport a feature
after the branch is created.
In your case, your patch was up for review for a while, and you made it
clear that you wanted it included for 20.06. It's on the rest of us to
ensure your patch gets reviewed in time for inclusion. It's not your
fault that we've been slow. You shouldn't get penalized for that.
All that being said, despite the fact that technically today is hard
freeze, I'm not creating the branch for 20.06 until Monday. So if we can
get it in before the end of the day Monday, it shouldn't even require a
backport to the branch. And if there's a compelling reason to delay the
branch creation, then that's fine too. These deadlines are of our own
making, and there's some flexibility built in just in case delays are
required.
Ihar
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
