diff mbox series

[ovs-dev,2/5] Remove TODO-SPLIT.rst.

Message ID 20240321161001.644616-3-dceara@redhat.com
State Changes Requested
Headers show
Series Various treewide fixes. | expand

Checks

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

Commit Message

Dumitru Ceara March 21, 2024, 4:09 p.m. UTC
All the TODO items listed in it have been addressed (for a while).
OVN includes OVS as a submodule nowadays and there's a documented way
of bumping the OVS submodule version when needed.

Signed-off-by: Dumitru Ceara <dceara@redhat.com>
---
 Makefile.am    |   1 -
 README.rst     |   3 +-
 TODO_SPLIT.rst | 116 -------------------------------------------------
 3 files changed, 1 insertion(+), 119 deletions(-)
 delete mode 100644 TODO_SPLIT.rst

Comments

Ilya Maximets March 21, 2024, 5:30 p.m. UTC | #1
On 3/21/24 17:09, Dumitru Ceara wrote:
> All the TODO items listed in it have been addressed (for a while).

That's a bold statement.  And I disagree. :)

> OVN includes OVS as a submodule nowadays and there's a documented way
> of bumping the OVS submodule version when needed.
> 
> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
> ---
>  Makefile.am    |   1 -
>  README.rst     |   3 +-
>  TODO_SPLIT.rst | 116 -------------------------------------------------
>  3 files changed, 1 insertion(+), 119 deletions(-)
>  delete mode 100644 TODO_SPLIT.rst
> 
> diff --git a/Makefile.am b/Makefile.am
> index bfc9565e8b..9febd492aa 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -108,7 +108,6 @@ EXTRA_DIST = \
>  	Vagrantfile-FreeBSD \
>  	.mailmap \
>  	TODO.rst \
> -	TODO_SPLIT.rst \
>  	ovn-architecture.7.xml \
>  	ovn-nb.ovsschema \
>  	ovn-nb.xml \
> diff --git a/README.rst b/README.rst
> index 428cd8ee87..b5ce2a164b 100644
> --- a/README.rst
> +++ b/README.rst
> @@ -39,8 +39,7 @@ in userspace and therefore requires no kernel modules to be installed.
>  
>  Until recently, OVN code lived within the Open vSwitch codebase. OVN has
>  recently been split into its own repo. There is much to do to complete this
> -split entirely. See the TODO_SPLIT.rst file for a list of known tasks that
> -need to be completed.
> +split entirely.
>  
>  What's here?
>  ------------
> diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst
> deleted file mode 100644
> index 5f11205bab..0000000000
> --- a/TODO_SPLIT.rst
> +++ /dev/null
> @@ -1,116 +0,0 @@
> -..
> -      Licensed under the Apache License, Version 2.0 (the "License"); you may
> -      not use this file except in compliance with the License. You may obtain
> -      a copy of the License at
> -
> -          http://www.apache.org/licenses/LICENSE-2.0
> -
> -      Unless required by applicable law or agreed to in writing, software
> -      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
> -      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
> -      License for the specific language governing permissions and limitations
> -      under the License.
> -
> -      Convention for heading levels in OVN documentation:
> -
> -      =======  Heading 0 (reserved for the title in a document)
> -      -------  Heading 1
> -      ~~~~~~~  Heading 2
> -      +++++++  Heading 3
> -      '''''''  Heading 4
> -
> -      Avoid deeper levels because they do not render well.
> -
> -========================
> -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.
> -
> -* Someone with a decent ability to write should give the README.rst file some
> -  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.

I don't think this particular item is done.  For example the RHEL
installation docs were not changed since the split and still describe
how to build OVS rather than OVN.

> -
> -* 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.
> -
> -* The ovs-sandbox is in a similar state to the tests directory. That is, the
> -  tutorial/ directory contains a copy of the ovs-sandbox script. Rather than
> -  copying the script wholesale, it probably makes more sense to refer to the
> -  ovs version of the script from the ovn repo. Running the sandbox should
> -  also be altered so that the base ovs-sandbox script doesn't do anything
> -  ovn-related. Rather, the ovn repo can start the sandbox by calling into
> -  ovs and then start the ovn parts after.

Two items above are not done either, but I'm not sure if they need to
be done.

> -
> -* 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.
Dumitru Ceara March 21, 2024, 5:40 p.m. UTC | #2
On 3/21/24 18:30, Ilya Maximets wrote:
> On 3/21/24 17:09, Dumitru Ceara wrote:
>> All the TODO items listed in it have been addressed (for a while).
> 
> That's a bold statement.  And I disagree. :)
> 

It's the only type of statements I make. :)

>> OVN includes OVS as a submodule nowadays and there's a documented way
>> of bumping the OVS submodule version when needed.
>>
>> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
>> ---
>>  Makefile.am    |   1 -
>>  README.rst     |   3 +-
>>  TODO_SPLIT.rst | 116 -------------------------------------------------
>>  3 files changed, 1 insertion(+), 119 deletions(-)
>>  delete mode 100644 TODO_SPLIT.rst
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index bfc9565e8b..9febd492aa 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -108,7 +108,6 @@ EXTRA_DIST = \
>>  	Vagrantfile-FreeBSD \
>>  	.mailmap \
>>  	TODO.rst \
>> -	TODO_SPLIT.rst \
>>  	ovn-architecture.7.xml \
>>  	ovn-nb.ovsschema \
>>  	ovn-nb.xml \
>> diff --git a/README.rst b/README.rst
>> index 428cd8ee87..b5ce2a164b 100644
>> --- a/README.rst
>> +++ b/README.rst
>> @@ -39,8 +39,7 @@ in userspace and therefore requires no kernel modules to be installed.
>>  
>>  Until recently, OVN code lived within the Open vSwitch codebase. OVN has
>>  recently been split into its own repo. There is much to do to complete this
>> -split entirely. See the TODO_SPLIT.rst file for a list of known tasks that
>> -need to be completed.
>> +split entirely.
>>  
>>  What's here?
>>  ------------
>> diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst
>> deleted file mode 100644
>> index 5f11205bab..0000000000
>> --- a/TODO_SPLIT.rst
>> +++ /dev/null
>> @@ -1,116 +0,0 @@
>> -..
>> -      Licensed under the Apache License, Version 2.0 (the "License"); you may
>> -      not use this file except in compliance with the License. You may obtain
>> -      a copy of the License at
>> -
>> -          http://www.apache.org/licenses/LICENSE-2.0
>> -
>> -      Unless required by applicable law or agreed to in writing, software
>> -      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
>> -      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
>> -      License for the specific language governing permissions and limitations
>> -      under the License.
>> -
>> -      Convention for heading levels in OVN documentation:
>> -
>> -      =======  Heading 0 (reserved for the title in a document)
>> -      -------  Heading 1
>> -      ~~~~~~~  Heading 2
>> -      +++++++  Heading 3
>> -      '''''''  Heading 4
>> -
>> -      Avoid deeper levels because they do not render well.
>> -
>> -========================
>> -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.
>> -
>> -* Someone with a decent ability to write should give the README.rst file some
>> -  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.
> 
> I don't think this particular item is done.  For example the RHEL
> installation docs were not changed since the split and still describe
> how to build OVS rather than OVN.
> 

Hmm, good point, I'll update those in v2.

>> -
>> -* 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.
>> -
>> -* The ovs-sandbox is in a similar state to the tests directory. That is, the
>> -  tutorial/ directory contains a copy of the ovs-sandbox script. Rather than
>> -  copying the script wholesale, it probably makes more sense to refer to the
>> -  ovs version of the script from the ovn repo. Running the sandbox should
>> -  also be altered so that the base ovs-sandbox script doesn't do anything
>> -  ovn-related. Rather, the ovn repo can start the sandbox by calling into
>> -  ovs and then start the ovn parts after.
> 
> Two items above are not done either, but I'm not sure if they need to
> be done.
> 

I don't think they need anything done either.  Maybe just rename
ovs-sandbox to ovn-sandbox.

>> -
>> -* 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.
>
Ilya Maximets March 21, 2024, 5:52 p.m. UTC | #3
On 3/21/24 18:40, Dumitru Ceara wrote:
> On 3/21/24 18:30, Ilya Maximets wrote:
>> On 3/21/24 17:09, Dumitru Ceara wrote:
>>> All the TODO items listed in it have been addressed (for a while).
>>
>> That's a bold statement.  And I disagree. :)
>>
> 
> It's the only type of statements I make. :)
> 
>>> OVN includes OVS as a submodule nowadays and there's a documented way
>>> of bumping the OVS submodule version when needed.
>>>
>>> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
>>> ---
>>>  Makefile.am    |   1 -
>>>  README.rst     |   3 +-
>>>  TODO_SPLIT.rst | 116 -------------------------------------------------
>>>  3 files changed, 1 insertion(+), 119 deletions(-)
>>>  delete mode 100644 TODO_SPLIT.rst
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index bfc9565e8b..9febd492aa 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -108,7 +108,6 @@ EXTRA_DIST = \
>>>  	Vagrantfile-FreeBSD \
>>>  	.mailmap \
>>>  	TODO.rst \
>>> -	TODO_SPLIT.rst \
>>>  	ovn-architecture.7.xml \
>>>  	ovn-nb.ovsschema \
>>>  	ovn-nb.xml \
>>> diff --git a/README.rst b/README.rst
>>> index 428cd8ee87..b5ce2a164b 100644
>>> --- a/README.rst
>>> +++ b/README.rst
>>> @@ -39,8 +39,7 @@ in userspace and therefore requires no kernel modules to be installed.
>>>  
>>>  Until recently, OVN code lived within the Open vSwitch codebase. OVN has
>>>  recently been split into its own repo. There is much to do to complete this
>>> -split entirely. See the TODO_SPLIT.rst file for a list of known tasks that
>>> -need to be completed.
>>> +split entirely.
>>>  
>>>  What's here?
>>>  ------------
>>> diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst
>>> deleted file mode 100644
>>> index 5f11205bab..0000000000
>>> --- a/TODO_SPLIT.rst
>>> +++ /dev/null
>>> @@ -1,116 +0,0 @@
>>> -..
>>> -      Licensed under the Apache License, Version 2.0 (the "License"); you may
>>> -      not use this file except in compliance with the License. You may obtain
>>> -      a copy of the License at
>>> -
>>> -          http://www.apache.org/licenses/LICENSE-2.0
>>> -
>>> -      Unless required by applicable law or agreed to in writing, software
>>> -      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
>>> -      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
>>> -      License for the specific language governing permissions and limitations
>>> -      under the License.
>>> -
>>> -      Convention for heading levels in OVN documentation:
>>> -
>>> -      =======  Heading 0 (reserved for the title in a document)
>>> -      -------  Heading 1
>>> -      ~~~~~~~  Heading 2
>>> -      +++++++  Heading 3
>>> -      '''''''  Heading 4
>>> -
>>> -      Avoid deeper levels because they do not render well.
>>> -
>>> -========================
>>> -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.
>>> -
>>> -* Someone with a decent ability to write should give the README.rst file some
>>> -  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.
>>
>> I don't think this particular item is done.  For example the RHEL
>> installation docs were not changed since the split and still describe
>> how to build OVS rather than OVN.
>>
> 
> Hmm, good point, I'll update those in v2.

There are few other docs.  On a quick glance the libopenvswitch-abi.rst
seems to be irrelevant for OVN.

> 
>>> -
>>> -* 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.
>>> -
>>> -* The ovs-sandbox is in a similar state to the tests directory. That is, the
>>> -  tutorial/ directory contains a copy of the ovs-sandbox script. Rather than
>>> -  copying the script wholesale, it probably makes more sense to refer to the
>>> -  ovs version of the script from the ovn repo. Running the sandbox should
>>> -  also be altered so that the base ovs-sandbox script doesn't do anything
>>> -  ovn-related. Rather, the ovn repo can start the sandbox by calling into
>>> -  ovs and then start the ovn parts after.
>>
>> Two items above are not done either, but I'm not sure if they need to
>> be done.
>>
> 
> I don't think they need anything done either.  Maybe just rename
> ovs-sandbox to ovn-sandbox.
> 
>>> -
>>> -* 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.
>>
>
diff mbox series

Patch

diff --git a/Makefile.am b/Makefile.am
index bfc9565e8b..9febd492aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -108,7 +108,6 @@  EXTRA_DIST = \
 	Vagrantfile-FreeBSD \
 	.mailmap \
 	TODO.rst \
-	TODO_SPLIT.rst \
 	ovn-architecture.7.xml \
 	ovn-nb.ovsschema \
 	ovn-nb.xml \
diff --git a/README.rst b/README.rst
index 428cd8ee87..b5ce2a164b 100644
--- a/README.rst
+++ b/README.rst
@@ -39,8 +39,7 @@  in userspace and therefore requires no kernel modules to be installed.
 
 Until recently, OVN code lived within the Open vSwitch codebase. OVN has
 recently been split into its own repo. There is much to do to complete this
-split entirely. See the TODO_SPLIT.rst file for a list of known tasks that
-need to be completed.
+split entirely.
 
 What's here?
 ------------
diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst
deleted file mode 100644
index 5f11205bab..0000000000
--- a/TODO_SPLIT.rst
+++ /dev/null
@@ -1,116 +0,0 @@ 
-..
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-      Convention for heading levels in OVN documentation:
-
-      =======  Heading 0 (reserved for the title in a document)
-      -------  Heading 1
-      ~~~~~~~  Heading 2
-      +++++++  Heading 3
-      '''''''  Heading 4
-
-      Avoid deeper levels because they do not render well.
-
-========================
-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.
-
-* Someone with a decent ability to write should give the README.rst file some
-  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.
-
-* The ovs-sandbox is in a similar state to the tests directory. That is, the
-  tutorial/ directory contains a copy of the ovs-sandbox script. Rather than
-  copying the script wholesale, it probably makes more sense to refer to the
-  ovs version of the script from the ovn repo. Running the sandbox should
-  also be altered so that the base ovs-sandbox script doesn't do anything
-  ovn-related. Rather, the ovn repo can start the sandbox by calling into
-  ovs and then start the ovn parts after.
-
-* 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.