Proposal for OpenBMC releases + migration

[Joseph Reynolds]

On 5/21/2018 1:49 PM, openbmc-request at lists.ozlabs.org wrote:
> In order for us to facilitate all member companies in the OpenBMC work
> planning process, I believe it is important for the project to adopt a
> formal release schedule. Release cycles allow member companies to plan
> on content being delivered, get a read on project priorities, and
> exchange design ideas on the best implementation. As with other
> projects, release dates would be fixed in time. If a feature didn't make
> the release cutoff, then it ships in the next release. This really helps
> drive prioritization of new functionality.
>
> As Brad commented in the community call today, let's start off the
> proposal with aligning with the Yocto project releases plus some time
> for project testing/hardening. Yocto releases are every 6 months, around
> May-October[1], so if we allow for a month of freeze and testing, that
> would be OpenBMC releases every June-November. Since June is next month,
> I'd propose that we start planning now for the November release.
>
> OpenBMC release ? November 2018
>
> Questions:
> How do we number releases? do we want to code name them?
> Do we want a stable branch/working branch organization?
> How long does the project maintain a stable branch? n-1? n-2?
> Do we want project milestones for content proposal, code freeze and release?
>
> [1]https://wiki.yoctoproject.org/wiki/Releases
>
> Kurt Taylor (krtaylor)
It is my understanding that one of the primary applications of OpenBMC 
is for use in servers that may have a life span of 7 years (wild 
guess).  Does that mean we should support selected OpenBMC releases for 
that long?  Or do we leave that work to the downstream projects that use 
OpenBMC?  Some groups will be required to remediate BMC security flaws 
for the lifetime of the server.

An alternative is a migration path.  For example, a server is placed 
into service in a data center, serviced by OpenBMC release N.  The 
server receives regular maintenance and updates as usual.  The BMC also 
receives updates to remediate its flaws.  When OpenBMC release N goes 
out of service, the administrator migrates to OpenBMC release N+1, and 
continues maintenance.

The "release upgrade/migration" replaces the OpenBMC code, while leaving 
its data intact: user authentication and authorization levels, event 
logs, FRUs, etc.  That implies the data must be forward compatible, 
specifically, OpenBMC release N+1 must be able to read/use/handle data 
from release N data.  Implicit is an assumption that the only way to 
update a BMC based on OpenBMC is by replacing the entire installed image.

IN SUMMARY, I think the OpenBMC project will need a forward migration 
path from each release N to release N+1.  And that means OpenBMC 
developers will need to consider how they will provide forward 
compatibility for data stored on the BMC.  For example, when release N+1 
is booted up, it will be expected to work with data that was created on 
release N.
-- 
Joseph Reynolds | 507.208.5420 | joseph-reynolds at charter.net
linkedin.com/in/joseph-reynolds