My take was that the primary benefit that would justify pursuing this would be an independent release schedule, but we don't have any changes (committed or pending) that raise that issue. The prime example for me was Python 3 support, where we really wanted it released, but had to wait about 8 months for the next ovs release. The new release schedule means more like 5-6 months, max, but perhaps a similar situation could arise.
My suggestion is to wait until something like that comes up again. The rest isn't a strong enough justification to me. -- Russell Bryant On Mon, Dec 12, 2016 at 4:34 PM, Ben Pfaff <b...@ovn.org> wrote: > I'm worried that my response here effectively shut down the proposal. > That wasn't my goal; if it's valuable, let's do it, but I want more > information first. > > On Mon, Nov 21, 2016 at 09:42:46PM -0800, Ben Pfaff wrote: > > On Tue, Nov 15, 2016 at 11:29:51AM -0600, Terry Wilson wrote: > > > The Python library isn't dependent on the code in the OVS tree. It > > > being in-tree has a few shortcomings. My rationale for recommending > > > the split: > > > > > > * Simple features and bugfixes for the Python lib can't be used by > > > other projects (like Neutron) until the very latest OVS release is > > > widely supported > > > > I am not sure that I understand why. Why would Neutron and other > > projects be more willing to use a pre-release version of an OVS Python > > library, than a pre-release version of OVS itself? Or do you mean that > > the OVS Python library would release more frequently than OVS itself? > > > > The following two bullets are related: > > > > > * Python 3 support is only available in version 2.6.0+ even though the > > > code would work for previous releases > > > > > > * Implying that the Python lib and OVS versions are related when they > > > aren't is confusing > > > > The Python library and OVS version numbers are indeed related, in that a > > given version of OVS is meant to work with the same version of the > > Python library, and vice versa. Maybe there is some flexibility in > > working with different versions, but if so then this is more by accident > > than design. > > > > Scanning the recent commits to the repository, it appears that the main > > dependency is just that the main OVS code requires a new-enough version > > of the Python code. Probably, this is not a big deal, but the split-off > > repos should explain the situation somewhere. > > > > As you suggest, maybe the Python code from 2.6.x would work with earlier > > versions of OVS. But this was not a foreseen use, so I would not want > > to recommend that users do this. If we split the repos and start > > thinking about this kind of possibility, then I agree that similar > > combinations could make sense for OVS 2.7.x+. > > > > > * A separate repo would allow adding committers that are familiar with > > > the Python code, but less familiar with the C code. > > > > I'd rather have only "committers", not "OVS committers" and "OVS Python > > library committers". We don't have "OVS committers" and "OVS Linux > > datapath committers" and "OVS Windows datapath committers" and "OVS-DPDK > > committers", for example. We trust our committers not to commit code > > without obtaining assurance that the code makes sense, through careful > > coding and at least one quality review. Part of that trust is trusting > > committers to recognize when their own understanding of a piece code is > > limited and therefore that they should obtain more or better reviews. > > In other words, I want to trust programmers who do not know C to commit > > to the C parts of OVS anyway, because they will take the trouble to get > > good advice. > > > > > * As a Python-only project, it could be more easily tested, built, and > > > packaged according to Python project best practices. > > > > I think that most of the Python tests run some part of OVS. I'm not > > sure how effective the Python library tests can be if OVS isn't > > available. > > > > > The current build process requires the Python code, but this is easily > > > remedied by using git submodules. People tend to reflexively dislike > > > them, but they are perfect for this application. The OVS tree can lock > > > to any particular commit for the new python-ovs repo and be guaranteed > > > that changes don't break the ovs build. I made a fork to show how > > > simple the change would be: > > > > > > https://github.com/otherwiseguy/ovs/commit/ > 6766131b42807829ea78dbc43d164db8926030e7 > > > > > > commit 6766131b42807829ea78dbc43d164db8926030e7 > > > Author: Terry Wilson <twil...@redhat.com> > > > Date: Mon Nov 14 16:03:43 2016 -0600 > > > > > > Move python dir to a submodule > > > > It's a straightforward change, yes, if it's valuable. > > > > Documentation and webpage updates would be needed to explain the new > > build process. > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
