| Deployment Bot (from Travis CI) | 6d7e6e9 | 2021-06-14 19:18:41 +0000 | [diff] [blame] | 1 | .. _stable-rules: |
| 2 | |
| 3 | ======================================= |
| 4 | op-build stable tree rules and releases |
| 5 | ======================================= |
| 6 | |
| 7 | Our stable tree process follows processes similar to other open source projects |
| 8 | such as the Linux Kernel and Buildroot, as do several OpenPOWER Firmware |
| 9 | components such as Skiboot and Petitboot. |
| 10 | |
| 11 | The purpose of a -stable tree is to give vendors a stable base to create |
| 12 | firmware releases from and to incorporate into service packs. New stable |
| 13 | releases contain critical fixes only. |
| 14 | |
| 15 | As a general rule, only the most recent op-build release gets a maintained |
| 16 | -stable tree. If you wish to maintain an older tree, speak up! For example, |
| 17 | with my IBMer hat on, we'll maintain branches that we ship in products. |
| 18 | |
| 19 | What patches are accepted? |
| 20 | -------------------------- |
| 21 | |
| 22 | * Patches must be obviously correct and tested |
| 23 | |
| 24 | * A Tested-by signoff is *important* |
| 25 | * A patch must fix a real bug |
| 26 | * No trivial patches, such fixups belong in main branch |
| 27 | * Not fix a purely theoretical problem unless you can prove how |
| 28 | it's exploitable |
| 29 | * The patch, or an equivalent one, must already be in master |
| 30 | |
| 31 | * Submitting to both at the same time is okay, but back-porting is better |
| 32 | |
| 33 | HOWTO submit to stable |
| 34 | ---------------------- |
| 35 | |
| 36 | 1. Make a pull request with "[stable op-build-N.N.y]" in subject (where N.N.y |
| 37 | is the stable branch to which you are targeting) |
| 38 | |
| 39 | * This targets the patch *ONLY* to the stable branch. |
| 40 | |
| 41 | * Such commits will *NOT* be merged into master. |
| 42 | * Use this when: |
| 43 | |
| 44 | a. cherry-picking a fix from master |
| 45 | b. fixing something that is only broken in stable |
| 46 | c. fix in stable needs to be completely different than in master |
| 47 | |
| 48 | If b or c: explain why. |
| 49 | * If cherry-picking, include the following at the top of your |
| 50 | commit message (or use the -x option to git-cherry-pick): :: |
| 51 | |
| 52 | commit <sha1> upstream. |
| 53 | * If the patch has been modified, explain why in description. |
| 54 | |
| 55 | 2. Add a comment on the PR indicating that a PR should also go to a stable |
| 56 | branch when making a Pull request to master |
| 57 | |
| 58 | * This targets the patch to master and stable. |
| 59 | * You can target a patch to a specific stable tree by putting that in the |
| 60 | comment |
| 61 | * You can ask for prerequisites to be cherry-picked. |
| 62 | |
| 63 | Trees |
| 64 | ----- |
| 65 | |
| 66 | * https://github.com/open-power/op-build/ (or via ssh at ``git@github.com:open-power/op-build.git`` ) |
| 67 | |
| 68 | * (branches are op-build-X.Y.y - e.g. op-build-2.0.y) |
| 69 | |
| 70 | * Some stable versions may last longer than others |
| 71 | |
| 72 | * So there may be op-build-2.0.y and op-build-2.4.y actively maintained |
| 73 | and op-build-2.0.y could possibly outlast op-build-2.4.y. |