diff mbox series

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

Message ID 20240321231535.695233-9-dceara@redhat.com
State Accepted
Headers show
Series Various treewide fixes. | expand

Checks

Context Check Description
ovsrobot/apply-robot success apply and check: success
ovsrobot/github-robot-_ovn-kubernetes success github build: passed
ovsrobot/github-robot-_Build_and_Test fail github build: failed
ovsrobot/github-robot-_ovn-kubernetes success github build: passed
ovsrobot/github-robot-_Build_and_Test fail github build: failed
ovsrobot/github-robot-_Build_and_Test success github build: passed
ovsrobot/github-robot-_ovn-kubernetes success github build: passed

Commit Message

Dumitru Ceara March 21, 2024, 11:15 p.m. UTC
As Ilya commented in the review of the V1 of this series [0] 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.

[0] https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412704.html

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

Comments

Dumitru Ceara March 22, 2024, 8:01 a.m. UTC | #1
On 3/22/24 00:15, Dumitru Ceara wrote:
> As Ilya commented in the review of the V1 of this series [0] 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.
> 
> [0] https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412704.html
> 
> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
> ---

Recheck-request: github-robot
Dumitru Ceara March 22, 2024, 1:12 p.m. UTC | #2
On 3/22/24 00:15, Dumitru Ceara wrote:
> As Ilya commented in the review of the V1 of this series [0] 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.
> 
> [0] https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412704.html
> 
> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
> ---

Recheck-request: github-robot-_Build_and_Test
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.