[ovs-dev] Bug#826780: Bug#826780: Please package OVS >= 2.6.0.dev1

[Terry Wilson]

On Thu, Jun 9, 2016 at 10:04 PM, Joe Stringer <joe at ovn.org> wrote:
>> On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant <russell at ovn.org> wrote:
>>> The real solution to making this less awkward would be to split the Python
>>> library out of the OVS git tree so that it can be released independently of
>>> OVS itself.  That way a proper verison could be released that includes
>>> Python 3 support.
>>
>> This would be very nice. There are some challenges to overcome. The
>> testing infrastructure between the Python and C implementations is
>> shared. Out of tree it becomes more a bit more difficult to make sure
>> that they stay in sync both feature and compatibility-wise. My gut
>> feeling is that it would still be worth the work, though. There's no
>> good reason for releases of the Python library to be tied OVS
>> releases.
>
> Setting aside the python3 compatibility issues, the typical number of
> commits to this library between releases is pretty small (<10). They
> seem to be largely independent of other changes in the OVS tree, but
> occasionally they are coupled to other changes.
>
> Is the proposal really fixing an ongoing issue or just a one-off? It
> seems like a lot of effort unless the pace of development on this
> library significantly increases and users really need a more frequent
> release cycle (for example, because they're releasing versions of
> their software more regularly than the OVS and need the latest and
> greatest python-ovs).

Any python patch I've done is something coming from want to use this
is neutron right now: dding the event hook, JSON speedups, etc. I'd
also like to add indexing for index columns. None of the changes have
had anything to do with what version OVS is. We could backport
features/improvements in the Python lib. But then we'd end up with
essentially the exact same code in each branch so 2.5.1 is the same
code as 2.6.1 and both run fine with OVS 2.4.0. :p It might also be
beneficial to have different (or just additional) committers for the
Python library. You don't want me touching the openflow code (yet!),
but I could certainly handle the Python lib for instance. :)

Terry