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