On 7/2/25 5:10 PM, Ilya Maximets wrote: > On 7/2/25 5:05 PM, Ilya Maximets wrote: >> Hi. As described in Documentation/internals/release-process.rst, we are >> in a "soft freeze" state: >> >> During the freeze, we ask committers to refrain from applying patches that >> add new features unless those patches were already being publicly >> discussed >> and reviewed before the freeze began. Bug fixes are welcome at any time. >> Please propose and discuss exceptions on ovs-dev. >> >> We should branch for version 3.6 in two weeks from now, on Wednesday, Jul 16. >> With that, release should be on Monday, Aug 18. >> >> >> Currently, on the mailing list we have a few patches and patch sets that were >> already discussed / reviewed to some extent, and we do also await new >> versions >> for several patches and patch sets for which changes were requested. These, >> of course, can be accepted. >> >> If there are some new patches that never been reviewed / not posted yet, >> please, propose an exception in reply to this email and it can be discussed. > > One potential exception I'm aware of (since I authored it) is a non-RFC > version > of the "original upcall PID" patch: > > https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ > > We're waiting for the kernel side of it to be accepted, but it received no > objections so far and looks promising (v2 is on the way): > https://lore.kernel.org/netdev/[email protected]/ > > The userspace change is quite simple, so, I hope, it should be safe to get > this > during the soft freeze. Of course, assuming that the kernel patch will be > accepted and we'll get a non-RFC version of the change in a reasonable time > for > review. > > Any objections on attempting to get this into 3.6?
I took the lack of responses here and the Acks on the patch as a lack of objections and applied the change. > > A case can technically be made for the packet re-ordering that this patch is > supposed to solve to be qualified as a bug, and so this not being a new > feature, > but a bug fix, that can even be backported later. But I'm not sure. We can revisit this part in the future, but we should at least wait until the kernel change is in the Linus' tree before doing so. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
