.. _release-process: 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 :ref:`stable-rules` 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).