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
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.
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 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.
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
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.
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.
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.
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 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 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.
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.
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.