On Fri, Feb 22, 2019 at 04:15:27PM -0500, Mark Michelson wrote: > On 2/22/19 4:01 PM, Ben Pfaff wrote: > > On Mon, Feb 18, 2019 at 09:50:56AM -0500, Mark Michelson wrote: > > > Hi everyone, > > > > > > I have completed a *rough* POC of an OVN/OVS code split. You can find it > > > at > > > https://github.com/putnopvut/ovn.git > > > > > > Please take a look at the README file since that highlights how the split > > > was done, as well as some known issues. > > > > > > My attitude towards this repo is that it is a throwaway prototype. It > > > essentially proves the concept that OVN can include OVS as a git subtree, > > > while not really attempting to do a production-ready job of > > > doing so. There is a lot of unfinished work. > > > > It looks like the sort of thing I'd expect to see. > > > > One thing I don't expect to see for a first cut or an nth cut is > > perfection. Stuff in corner cases is going to be broken. That's the > > nature of big changes. We'll fix them as we notice them. > > > > The manpages.mk errors are from the rule in the Makefile that tries to > > rebuild manpages.mk. That's why touching it helps, since it keeps the > > Makefile from trying to rebuild it. > > > > What do you think is your next step? > > > > Hi Ben, > > Thanks for the reply. My current step is to get buy-in for this approach. If > people have suggestions for improvement or outright disapproval (with > logical reasoning of course), then I'll iterate and try to take those > suggestions into consideration. > > If people are 100% cool with the approach I've taken, then the next step > will be to come up with a plan to officially split the OVN code out from > OVS. It'll need a plan for a few reasons: > > 1) We'll need to get an official OVN repo to perform the work in.
That is easy. I (or any other OVS committer) can create one under the openvswitch organization on github. I'm happy to do so whenever you like, even now. There's also the "ovn-org". Justin is the sole owner of that org currently. I guess he'll probably add more people. (It's easy to transfer repos between orgs, so no worries about that.) > 2) We'll essentially need to have a "freeze" on OVN development during the > split. Otherwise, changes that occur between the start of the split and the > completion of the split could get lost. Or it will require some porting of > the changes between repos. Either way, not a fun task. Good point. > 3) We'll want to have testing plans in place. Tests will need to be focused > on ensuring that OVN works with compatible versions of OVS. Compatibility is > something that we've avoided trying to make official stances on, but that > could be a sub-item to perform here as well. Do you plan to make a proposal here? Are you more concerned about OVN or OVS for testing? It's easy for OVN to accidentally add a dependency on some later-than-intended version of OVS or OVSDB (although maybe just testing with the intended version helps?) but it's also easy for OVS to accidentally make some change that breaks OVN. > 4) We'll want to be sure we're all on the same page regarding when the OVN > split occurs. Will we do it at the same point that OVS 2.12 is being > released, or will we do it as soon as possible and have OVN start its own > versioning independent of OVS immediately? Is there any advantage to waiting, once we're ready? This might be a good time to increment the OVS major number to 3.0. > Once all of the above are determined, then I think it's a matter of > essentially re-doing what I've done already, but in a more official capacity > (i.e. using an official repo, making more coherent commits, ensuring builds > work across platforms). Once there is a functioning repo in which work can > be done, we can work on the finer details (i.e. removing additional > irrelevant files, reworking documentation). And once all of that is done, > then I think the administrative details can become important (i.e. > determining committers, updating websites, mailing lists, etc.) Oh my, it'll take a long time to get that right. I wonder whether OVN should adopt a more "modern" workflow, such as Github pull requests instead of emails. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
