diff --git a/release/release-notes.md b/release/release-notes.md
deleted file mode 100644
index 1d7d3d2..0000000
--- a/release/release-notes.md
+++ /dev/null
@@ -1,311 +0,0 @@
-# OpenBMC Release Notes
-
-The OpenBMC project now has a regular release cycle with stable branches
-starting with the 2.6 release. Prior release tag notes are also listed here for
-completeness.
-
-Read more about the release process here:
-https://github.com/openbmc/docs/blob/master/release/release-process.md
-
-For information on how to checkout a particular branch or tag, see:
-https://github.com/openbmc/openbmc/wiki/Releases
-
-## OpenBMC Releases
-
-### 2.9 January, 2021
-
-#### Features:
-
-- Yocto refresh to "Gatesgarth" 3.2
-- Partial Redfish support for properties from the 2020.1, 2020.2, and 2020.3
-  Schemas
-- Redfish support for: Dump, Multiple Firmware Image Support
-- Added webui-vue, a web-based user interface built of Vue.js
-  - A replacement for phosphor-webui
-  - Uses Redfish
-  - Ability to easily theme to meet brand guidelines
-  - Language translation-ready
-  - Improved user experience
-
-#### Fixes and Known Issues/Limitations:
-
-#### Security audit results:
-
-### 2.8 June, 2020
-
-#### Features:
-
-- Yocto refresh to "Dunfell" version 3.1
-- Redfish support for:
-  - full certificate management
-  - complete LDAP management
-  - full sensor support
-  - event service schema
-  - task schema
-- Move to Redfish Specification 1.9.0
-- Redfish support for 2020.1 Schemas
-- GUI enhancements:
-  - LDAP
-  - certificate management
-- mTLS HTTPS authentication
-- Partial PLDM Support
-- Partial MCTP Support
-
-#### Fixes and Known Issues/Limitations:
-
-- Enabling and disabling DHCP via Redfish is not working (openbmc/bmcweb #127)
-- LDAP login will fail for users belonging to the redfish group
-- Unable to configure IP address on VLAN interface (openbmc/openbmc #3668)
-- Unable create VLAN via IPMI (openbmc/phosphor-net-ipmid #12)
-
-#### Security audit results:
-
-- IPMI RMCP+ cipher suite 3 was removed, leaving only cipher suite 17
-  (https://github.com/openbmc/phosphor-net-ipmid/commit/4c494398a36d9f1bdc4f256f937487c7ebcc4e95)
-- The fix for CVE-2020-14156 is present. This affects images that have IPMI
-  users (https://github.com/openbmc/openbmc/issues/3670)
-
-### 2.7 Aug 5, 2019
-
-#### Features:
-
-- Yocto refresh to "Warrior" version 2.7
-- Removal of Python for footprint reduction: python is no longer required for
-  the meta-phosphor layer and its defaults
-- Finished up KVM over IP: adds the infrastructure to allow KVM sessions through
-  the webui
-- NVMe-MI over SMBus
-- ECC logging for BMC: service to monitor EDAC driver and BMC log
-- Partial PLDM Support
-- Partial MCTP Support
-- Redfish support for: partial Certificates, local user management, partial
-  LDAP, network, event logging, DateTime, boot devices, firmware update,
-  inventory and sensors
-- phosphor-ipmi-flash support: sending firmware images over IPMI, pci-aspeed,
-  and other mechanisms for host-driven updates
-- GUI enhancements: multiple user support, virtual media, KVM
-
-#### Fixes and Known Issues/Limitations:
-
-- Yocto Warrior subtree refresh applied (24230)
-
-### 2.6 Feb 4, 2019
-
-**_First Release as Linux Foundation Project_**
-
-#### Features:
-
-- Yocto refresh to "Thud" version 2.6
-- GUI enhancements: SNMP and Date/Time
-- Serial over Lan
-- IPMI 2.0 support
-- Partial Redfish support
-- Kernel updated to 4.19 LTS
-
-#### Known Issues/Limitations:
-
-- Support dropped for the ipmitool nameless option
-
-## Release tags with notes prior to release branching
-
-### v1.0.5 Aug 23, 2016
-
-#### Updates:
-
-- Cache all inventory properties and preserve inventory during BMC firmware
-  update (#487)
-- Update the power button behavior on Barreleye to:
-  - Short press: Only power on. Remove the power off action
-  - Long press (>3 seconds): Hard power off
-
-### v1.0.4 Aug 8, 2016
-
-#### Changes:
-
-- Kernel version update:
-  - Stable release 4.4.16
-  - Power button debounce fix for Barreleye
-  - Fix for an NCSI race condition that caused the device to not come up
-    (openbmc/phosphor-networkd#18)
-- Load inventory from cache (#487)
-- Start host watchdog timer after magic sequence (openbmc/skeleton#127)
-- Restart REST server when network configuration changes
-  (openbmc/phosphor-rest-server#24)
-
-### v1.0.3 Jul 18, 2016
-
-#### Updates:
-
-- Fix issue in Host IPMI inventory due to versioned shared libraries (#423)
-
-### v1.0.2 Jul 5, 2016
-
-#### Updates:
-
-- Add ability to perform BMC code update at runtime and get the BMC code update
-  progress through REST
-- Fix event log directory duplication during BMC code update
-- Fix hwmon attribute not being polled after failure
-
-### v1.0.1 Jun 27, 2016
-
-#### Release Notes:
-
-- Fix encode firmware version in BCD format
-- Handle floating point sensor values
-- Performance improvements to prevent services from failing to start
-- Extend the mapper service startup timeout to ensure it starts up
-- Enable DNS resolution from DHCP
-
-### v1.0 Jun 20, 2016
-
-#### Features:
-
-- Enable one-time vs permanent host boot option
-- Enable handling of host checkstop gpio
-- Handle endianness in IPMI eSEL function
-- Improve IPMI error handling
-- Add IPMI Travis CI
-- Fix host hanging due to inventory upload
-- Fix i2c-tools SRC url syntax
-- Fix sensor attribute reading
-- Fix limit of number of event logs
-- Add adm1278 driver into the Linux kernel by default
-- Automatically restart phosphor service processes
-- Enable out-of-tree kernel device trees
-- Update pflash version
-- Update u-boot version
-  - Fix memory corruption
-- Update kernel version
-  - Stable 4.4.12 release
-  - Pick up i2c completion fix
-  - Add power button debounce function for Barreleye
-- Remove development tool rest-dbus from Barreleye image
-- BMC performance improvements
-
-### v0.8 May 20, 2016
-
-#### Updates:
-
-- Update pflash version
-- Host console support for local tty mirroring
-- Cap number of event logs at 128
-- BMC boot performance improvements
-- Linux updates:
-  - Update to 4.4.10 release
-  - Fix network cable link detection
-  - Support for VOUT sampling to the adm1275 driver
-  - Add eeprom to barreleye device tree
-  - Fix OCC sensor activation
-
-### v0.7 May 5, 2016
-
-#### Updates:
-
-- Update to kernel 4.4
-- Update to yocto 2.0.1
-- Use upstream pflash
-
-#### Features:
-
-- Device tree
-- New host console.
-  - Documentation: https://github.com/openbmc/docs/blob/master/console.md
-- REST association support
-- Dmidecode support
-- New REST interface to query network type (dhcp/static) under
-  NetworkManager->GetAddressType
-
-#### Fix:
-
-- Add CPU1 fru data to inventory
-
-### v0.6.1 Mar 22, 2016
-
-#### Fixes:
-
-- JFFS2 corruption
-- random segmentation faults
-- keep event logs from filling up flash. They are limited to 200K
-- OCC 12core fix
-- PCIe slot presence detect
-- SCU fix for networking issue
-
-### v0.6 Mar 7, 2016
-
-#### New features:
-
-- Immediate MAC address set via IPMI and REST; no reboot necessary
-- full user setup via REST
-- Boot to RAM filesystem so SOCFlash and pflash can be used from host
-- ADM1278 support
-- Custom LED blink rate
-- inARP support
-
-#### Fixes:
-
-- ipmid memory leak
-- SBE reboot issue
-
-### v0.5 Feb 17, 2016
-
-#### New Features:
-
-- Automatically run fsck to avoid file system corrupt
-- Full LAN get/set support via REST and ipmitool
-- User setup via REST support
-- NCSI driver enhancements
-- Virtual UART; improved hconsole
-- Persistent event logs
-- Persistent UUID based on /etc/machine-id
-- Full LED support
-
-### v0.4 Feb 4, 2016
-
-#### New Features:
-
-- Persistent file system
-- network configuration is persistent across boots and flashing
-- LAN set functions
-- Selectable flash update (u-boot, initramfs, kernel, settings)
-- fw utils for update u-boot environment variables
-- power capping and measurements
-- power restore policy
-
-#### Notes/Limitations:
-
-- Currently using ext4 for R/W file system. Need to migrate to JFFS which is
-  designed for flashes and more resilient to AC power loss. Please 'poweroff'
-  BMC before pulling AC power for now
-
-#### Missing Functions:
-
-- Persistent event logs
-- LAN get functions
-- User set/get functions
-- Proper LED representation
-
-### v0.2 Dec 4, 2015
-
-#### Release Notes:
-
-- Added CPU thermal sensors (/org/openbmc/sensors/temperature/cpu0 and 1)
-- Added full soft power off and reset support from host or BMC
-- Reboot issue fixed
-- Power button fixed
-- Network crash issue fixed
-- Added delete event log from REST
-- Cleaned up inventory
-- consistent states
-- io_board fru is populated from eeprom
-
-#### Known issues:
-
-- OCC driver unloading and loading prints harmless error messages to console
-- About 1 out of every 5 boots you will see the ftgmac driver print out a trace
-  stack. This appears to be harmless, but we are investigating
-
-#### Not supported:
-
-- Sensor thresholds
-- Setting boot options through REST
diff --git a/release/release-process.md b/release/release-process.md
deleted file mode 100644
index 1299df4..0000000
--- a/release/release-process.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# OpenBMC Release Process
-
-The OpenBMC release process document is the output of the Release Planning work
-group. This documents the set of topics that have been discussed and agreed upon
-to date, defining such things as the release process and schedule, milestones,
-content definition and feature prioritization. All the decisions were made in
-the work group meetings, with representatives from each member company.
-
-https://github.com/openbmc/openbmc/wiki/Release-Planning
-
-## Release Cycle
-
-### Schedule
-
-OpenBMC has its initial formal release branch as a Linux Foundation project in
-February 2019, with a new release branch following every 6 months. Releases are
-purposefully offset from Yocto releases by a few weeks to allow for integration
-and testing. Member companies are expected to test a release candidate on their
-platform and report their findings.
-
-### Versioning
-
-The OpenBMC release will follow the Yocto numbering with slight modification to
-allow for build information. The release version will follow the form:
-Major.Minor.Fix.obmc-build. For example:
-
-`2.6.4.obmc-2`
-
-This would be interpreted as major release 2, minor release 6, fix release 4,
-build 2.
-
-### Milestones
-
-Milestones are important dates within a release cycle. The milestone dates
-agreed to are as follows: Design, Code, Freeze, and Release. The milestones will
-each have entry and exit criteria. Milestone dates currently are not yet
-implemented.
-
-#### Design
-
-This is the date in the release cycle when a feature's design must be discussed
-openly and completed. The design should follow the published design template and
-be merged before this milestone. If this is not met, then the feature is at risk
-for not being merged for the forming release cycle.
-
-The Design Template can be found here:
-https://github.com/openbmc/docs/blob/master/designs/design-template.md
-
-#### Code
-
-This milestone represents some major functionality that has to be completed by
-this date in order for the feature to be delivered on time. It is a checkpoint
-for the developers doing the work to evaluate and commit to for having that part
-complete. Globally there can be one or more code milestones established, but
-currently these are TBD.
-
-#### Freeze
-
-This is the date where the release content is frozen, that is, no new major
-content will be accepted. This is necessary to allow time for the new features
-to be fully tested. Any defects found will be evaluated to be included or not,
-based on how close the release milestone is, and how much the defect impacts
-other components and features. Feature freeze will occur 2 weeks before the
-release milestone. Release tagging/branching can accommodate master development
-efforts to continue while a release candidate is being tested.
-
-The [security working group][] should provide guidance to the community about
-security aspects of the planned release. The idea is to provide input for the
-[release notes][] and actionable advice to the [test work group][].
-
-The [test work group][] should indicate what testing was performed and the
-results of that testing. The idea is to fix problems and provide input to the
-[release notes][].
-
-[security working group]:
-  https://github.com/openbmc/openbmc/wiki/Security-working-group
-[test work group]: https://github.com/openbmc/openbmc/wiki/Test-work-group
-[release notes]:
-  https://github.com/openbmc/docs/blob/master/release/release-notes.md
-
-#### Release
-
-The release milestone is the release date. It is defined as happening some time
-within a targeted release week. It is desired to have the release happen as soon
-as possible within the release week, but the week is given to allow for typical
-infrastructure problems to occur and be fixed in order for the release to
-happen.
-
-The release date is a fixed time frame and cannot be moved. If a feature is not
-done by the freeze milestone, then it will not be in that release, it will have
-to be included in the next release cycle. The release date will not float out
-until the feature is complete.
-
-The updated [release notes][] should be merged into the project.
-
-## Release Content
-
-### Content Input
-
-Community members define release content by inputting needed work into the
-release management tool(s) specified below. Typically the content is a feature
-that a particular company needs and one that they are willing to allocate some
-resources to see completed. The feature does not need to be fully staffed by
-that company, unless it is critical to that company and no other community
-member is willing to contribute.
-
-Release content is disclosed regardless of resource commitment because the
-community consists of not just member companies, but individuals interested in
-furthering OpenBMC. These community members may be willing to contribute to a
-feature.
-
-### Prioritization
-
-Prioritization happens naturally with listing the content proposed for a release
-cycle. If every community member participating in the Release Planning work
-group wants a particular feature and agree to help staff the effort, it
-automatically becomes a higher priority than an item that is mildly needed and
-not staffed.
-
-Just as with the content being fully disclosed, it is important to maintain a
-list of medium priority work that didn't make the release cut, as it may be an
-area that a new community member would like to start working on.
-
-### Work Group Formation
-
-Work groups form in the open around features for a release, not around company
-boundaries. Work groups would definitely be needed for work spanning releases,
-or high priority features with multiple community members. These work groups
-need a lead to form and guide the group through the release milestones and to
-deliver a well designed and tested feature.
-
-Work groups can be formal or not depending on the work needing to be done and
-the community member style. They can consist of email to the list or formal
-weekly meetings via Discord or call to discuss designs and progress.
-
-### Backlog
-
-The backlog is simply the proposed release features that did not make the
-release plan. They will be additional input for the next release cycle. They are
-also available for new community members looking for a new project to drive if
-none of the current work is within their expertise.
-
-### Release Management Tools
-
-Initially a Google spreadsheet was used, then Github issues/labels, but neither
-found acceptance or traction in the community. Currently broad features are
-listed in the wiki:
-
-https://github.com/openbmc/openbmc/wiki/Current-Release-Content