[ovs-dev] releasing 2.6: branch Aug 1, release Sep 15

Jesse Gross jesse at kernel.org
Tue Jul 26 21:24:19 UTC 2016


On Sun, Jul 24, 2016 at 10:53 AM, Ben Pfaff <blp at ovn.org> wrote:
> On Sun, Jul 24, 2016 at 08:39:31AM -0300, Thadeu Lima de Souza Cascardo wrote:
>> On Sat, Jul 23, 2016 at 08:59:35AM -0700, Ben Pfaff wrote:
>> > The proposed Open vSwitch release schedule calls for branching 2.6 from
>> > master on Aug. 1, followed by a period of bug fixes and stabilization,
>> > with release on Sep. 15.  The proposed release schedule is posted here
>> > for review:
>> >         https://patchwork.ozlabs.org/patch/650319/
>> >
>> > I don't yet know of a reason to modify this schedule.
>> >
>> > If you know of reasons to change it, now is an appropriate time to bring
>> > it up for discussion.  In addition, if you have features planned for 2.6
>> > that risk hitting master somewhat late for the branch, it is also a good
>> > time to bring these up for discussion, so that we can plan to backport
>> > them to the branch early on, or to delay the branch by a few days.
>>
>> I would like to see the rtnetlink patchset included. One of things
>> that needs to happen before that is taking those decisions about
>> netdev_open and the existence of conflicting port types with the same
>> name. For example, a system interface and an interface in the database
>> with the same name but a different type.
>>
>> I will post some comments on the discussion we already have opened for
>> that.
>>
>> Just wanted to take the opportunity to mention this expectation of
>> getting those into 2.6.
>
> For that feature, I need to defer to Jesse (added to the thread).

I think since there isn't yet a patch for this yet that is about ready
to be applied, we'll need to make a call at the time the code is
applied to master. If it's one day after we branch, sure that's fine;
one day before release, obviously not; anything in the middle we'll
need to decide.

However, based on the code that has been sent out previously, I think
this is mostly infrastructure at this point rather than user-visible
changes. It would allow other features to be built on top of it but
that would be a follow on change. If that's the case, is there any
particular reason to try to get this in 2.6?



More information about the dev mailing list