Proposal for OpenBMC releases

[krtaylor]

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)