diff mbox series

[ovs-dev,v2,6/8] Update post OVS-OVN split TODO list.

Message ID 20240321230734.694333-8-dceara@redhat.com
State Rejected
Headers show
Series Various treewide fixes. | expand

Commit Message

Dumitru Ceara March 21, 2024, 11:03 p.m. UTC
As Ilya commented in the review of the V1 of this series the statement
that "all the TODO items listed in it have been addressed" is indeed
"a bold statement".  However quite a few don't seem applicable anymore.

Signed-off-by: Dumitru Ceara <dceara@redhat.com>
---
 TODO_SPLIT.rst | 73 --------------------------------------------------
 1 file changed, 73 deletions(-)
diff mbox series

Patch

diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst
index 9c65f77d87..cdc2d25ba7 100644
--- a/TODO_SPLIT.rst
+++ b/TODO_SPLIT.rst
@@ -25,9 +25,6 @@ 
 OVN/OVS Split To-do List
 ========================
 
-Immediate tasks
----------------------------
-
 * There are likely many unused files throughout the source tree
   since they pertain to OVS rather than OVN. These can also be removed from the
   repo.
@@ -36,73 +33,3 @@  Immediate tasks
   polish (or even just rewrite it. I won't be offended).
 
 * Cleanup the acinclude.m4 and m4 folder
-
-Immediate to Short-term tasks
------------------------------
-
-* The Documentation/ directory can use an overhaul. Non-OVN content can be
-  removed. The installation guide and tutorials should be reworked to be
-  geared towards OVN specifically instead of OVS.
-
-* The tests/ directory contains copies of all "utility" files from the ovs
-  repo. These files could be removed in favor of using the files directly
-  from the ovs repo instead of the copy. As an example, ofproto-macros.at could
-  be removed from the tests/ directory, and we could reference the version in
-  the ovs repo instead. There are many other files that this could be done with.
-
-* OVN code needs to be removed from the OVS repo. This should be mostly
-  straightforward with a couple of exceptions. There is an include/ovn/
-  directory in the ovs repo that should be moved to the ovn repo instead of
-  being removed. The other challenge is updating the ovsdb clustering tests.
-  They currently make use of the OVN database schemas. They will need to be
-  updated not to rely on something from OVN.
-
-* The rhel/ and debian/ directories need updating and testing so that they can
-  build ovn. They also need to be modified so that they no longer can build ovs
-  packages.
-
-Short to Medium-term tasks
---------------------------
-
-* There are several non-code subdirectories in the ovn repo that have not
-  been updated from how they existed in the OVS repo. It should be evaluated
-  if there is potential use to modify these to be useful for OVN or if they
-  should just be removed. Examples include the poc/ and xenserver/ directories.
-
-Medium to Long-term tasks
--------------------------
-
-* The goal is to eventually not require having ovs as a subtree in the ovn
-  repo. Using variables in Makefiles goes a short way towards realizing
-  this goal, but it only partially gets us there. We still
-  refer to the ovs subtree directly in certain areas, most notably the
-  tests/ directory. Getting rid of the ovs subtree can be thought of as a
-  two-step process:
-
-  1) Remove all direct references to the ovs subtree from the build system. By
-  doing this, it will be possible to have an ovs source repo checked out at
-  some other location and have ovn refer to that by using variables.
-
-  2) Alter ovs's build so that it places headers, utilities, etc. in known
-  locations on disk when it installs. This way, rather than referring to
-  an ovs source repo, we can refer to installation directories in the ovn
-  build system. This way, it could be possible to build ovn just by installing
-  the development package of ovs as a prerequisite.
-
-* A plan needs to be developed for compatibility between OVN and OVS. There
-  are several facets to this
-
-  1) We need to try to determine a policy with regards to what OVS versions
-  OVN will be compatible with.
-
-  2) The ovs subtree in ovn currently is the master branch of ovs at the time
-  that the ovn repo was split off. It likely will result in a more stable
-  environment to use a released version of ovs as our basis instead of an
-  arbitrary commit from mid-release.
-
-  3) While ovn was housed in the ovs repo, it was sometimes necessary to
-  update ovs or ovsdb code in order to facilitate a new ovn feature. Or it
-  might be necessary to fix a bug in ovs in order to fix a bug in ovn. With ovn
-  split away, there needs to be a way that ovn developers can contribute changes
-  to ovs when necessary but also not have to wait for those changes to be
-  available in an ovs release to be able to use them in ovn.