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