From 4ba31045e46b54e8b3b3d240858f83a60b9ef49c Mon Sep 17 00:00:00 2001 From: aszlig Date: Fri, 18 Dec 2015 14:50:47 +0100 Subject: [PATCH] nixpkgs manual: more strict commit policy (close #11609) --- doc/submitting-changes.xml | 73 +++++++++++++++++++++++++++++++------- 1 file changed, 61 insertions(+), 12 deletions(-) diff --git a/doc/submitting-changes.xml b/doc/submitting-changes.xml index 0fd1954c528b..0b09dffbb2d3 100644 --- a/doc/submitting-changes.xml +++ b/doc/submitting-changes.xml @@ -261,23 +261,72 @@ Additional information. Hydra builds for master and staging should not be used as testing platform, it's a build farm for changes that have been already tested. - -Master should only see non-breaking commits that do not cause mass rebuilds. - - - -Staging should only see non-breaking mass-rebuild commits. That means it's not to be used for testing, and changes must have been well tested already. Read policy here. - - - -If staging is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days, merge into master, then resume development on staging. Keep an eye on the staging evaluations here. If any fixes for staging happen to be already in master, then master can be merged into staging. - - When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people's installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra. +
+ Master branch + + + + + It should only see non-breaking commits that do not cause mass rebuilds. + + + +
+ +
+ Staging branch + + + + + It's only for non-breaking mass-rebuild commits. That means it's not to + be used for testing, and changes must have been well tested already. + Read policy here. + + + + + If the branch is already in a broken state, please refrain from adding + extra new breakages. Stabilize it for a few days, merge into master, + then resume development on staging. + Keep an eye on the staging evaluations here. + If any fixes for staging happen to be already in master, then master can + be merged into staging. + + + +
+ +
+ Stable release branches + + + + + If you're cherry-picking a commit to a stable release branch, always use + git cherry-pick -xe and ensure the message contains a + clear description about why this needs to be included in the stable + branch. + + An example of a cherry-picked commit would look like this: + +nixos: Refactor the world. + +The original commit message describing the reason why the world was torn apart. + +(cherry picked from commit abcdef) +Reason: I just had a gut feeling that this would also be wanted by people from +the stone age. + + + +
+