111 lines
4.4 KiB
ReStructuredText
111 lines
4.4 KiB
ReStructuredText
|
.. _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).
|