Development and Release Process

Skiboot follows the release cycle of op-build, so that each new op-build has a new stable skiboot. Currently, this means that we release once every six weeks (or so). Our goal is to have roughly the first 4 weeks of a 6 week cycle open for merging new features, and reserving the final two weeks for stabilisation efforts after the first -rcX release.

It is strongly preferred to have new features (especially new APIs and device tree bindings) to come in early in the cycle.

Once the final release is cut, the Skiboot stable tree rules and releases process takes over.

Our process has evolved, and will so into the future. It’s inspired by the Linux process, but not a slave to it. For example, there is currently not the volume of patches to justify a next tree.

Here’s how some of the recent (at time of writing) releases have gone:

Date	Release
Oct 31st 2017	v5.9
Feb 6th 2018	v5.10-rc1
Feb 9th 2018	v5.10-rc2
Feb 15th 2018	v5.10-rc3
Feb 21st 2018	v5.10-rc4
Feb 23rd 2018	v5.10
Mar 28th 2018	v5.11-rc1
Apr 6th 2018	v5.11

Lifecycle of a patch

Roughly speaking, a patch has the following lifecycle:

• Design

  It is best to do design work in the open, although sometimes this is hard when upcoming unannounced hardware is involved. Often, it can be useful to post an RFC design or patch to encourage discussion. This is especially useful when designing new OPAL APs or device tree bindings. Never be afraid to send a patch (or series of patches) as RFC (Request for Comment) with whatever disclaimer you deem appropriate.

  Once you have a design, sharing it is an important part of the process of getting the applicable code upstream. Different perspectives are important in coming to elegant solutions, as is having more than one person understand the reasoning behind design decisions.

• Review and Test

  Once you think your patch is a state suitable for merging, send it to the mailing list for others to review and test. Using git format-patch and git send-email is good practice to ensure your patches survive being sent to the list. Ensure you have followed CONTRIBUTING.md and have your Signed-off-by present on your patches (git commit -s will add this for you).

  It is good practice to solicit review from an expert in the area of code you’re modifying. A reviewer will add their Reviewed-by or Acked-by tags as replies, as will anybody testing it add Tested-by. The aim of reviewing and testing code before we merge it is to limit any problems to the smallest number of people possible, only merging code we are collectively confident that will improve life for all users and developers.

• Merged to master

  The maintainer as merged your patches to the development tree (the ‘master’ git branch). Soon after this, many more people are going to be running your code, so good review and testing helps ensure your inbox isn’t flooded with bug reports.

  If your patch has also been sent to the stable tree, it’s possible it also gets merged there soonafter.

• Stable release

  Once a stable release is made, it’s likely that your code makes its way into vendor’s firmware releases via their test cycles.

• Bug fixes and maintenance

  Bugs are a fact of life, sometimes in our own code, sometimes in others, and sometimes in hardware. After your patch is accepted, being available for input on possible bugs found and possible fixes is invaluable so that all can ship high quality firmware.

On closed source branches and forks

Even though the license that skiboot is distributed under does allow you to keep your changes private, we (the skiboot developers) cannot in any way provide support on the resulting code base.

Additionally, the broader PowerPC Linux community has neither the capacity, time, or resources to support Linux running on such closed source forks. The kernel developers have said that patches to the kernel to support or work around closed skiboot changes will not be accepted upstream.

If you keep your changes private, you are entirely on your own.

License

Skiboot is licensed under the Apache 2.0 license (see the LICENSE file in the source tree for the full text).

Portions (e.g. our libc, CCAN modules we use) are made available under a CC0, BSD, or BSD-MIT license (see LICENSE files for specifics).