Move release docs to release/ dir

Created a release/ dir and moved release docs to it.
Renamed release docs with a - (this is the convention used in
the other docs).
Fixed the link release-notes.md

Change-Id: I565ccb38f55dbdc4fcf84a743bd7928c826dda30
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>

2 files changed, 353 insertions, 0 deletions

diff --git a/release/release-notes.md b/release/release-notes.md
new file mode 100644
index 0000000..e935014
--- /dev/null
+++ b/release/release-notes.md
@@ -0,0 +1,232 @@
+# 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.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
new file mode 100644
index 0000000..c0b2965
--- /dev/null
+++ b/release/release-process.md
@@ -0,0 +1,121 @@
+# 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. You are encouraged to get involved and contribute. The meeting
+information is available on the OpenBMC wiki:
+
+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 months to allow for
+integration and testing.
+
+### 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. Even though OpenBMC will follow the Yocto release numbering, code
+names for OpenBMC releases are still TBD.
+
+### 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.
+
+#### 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 4 weeks before the
+release milestone.
+
+How the release freeze will be done with regard to freeze and branch
+immediately or to freeze and test, branching on the release date is still TBD.
+
+#### 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.
+
+## 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 IRC 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
+We are initially using a Google spreadsheet, but the desire is to move to a
+better tool to track and manage content and schedules. Several have been
+proposed but selection is still TBD.