Skip to content

More strict commit policy for stable branch #11609

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
aszlig wants to merge 5 commits into from
Closed

More strict commit policy for stable branch #11609

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
52b11a0
doc: More strict commit policy for stable branch.
aszlig Dec 10, 2015
b425fc7
doc: Improve cherry-picked commit message example.
aszlig Dec 10, 2015
ae5c6af
doc: Add a note about using git cherry-pick -x.
aszlig Dec 10, 2015
1465032
doc: Split commit-policy into sections by branch.
aszlig Dec 10, 2015
18b9e73
doc: Add -e flag git cherry-pick and fix wording.
aszlig Dec 11, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 60 additions & 11 deletions doc/submitting-changes.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -262,21 +262,70 @@ Additional information.
</listitem>

<listitem>
<para>Master should only see non-breaking commits that do not cause mass rebuilds.</para>
<para>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.</para>
</listitem>
</itemizedlist>

<listitem>
<para>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. <link xlink:href="http://comments.gmane.org/gmane.linux.distributions.nixos/13447">Read policy here</link>.</para>
</listitem>
<section>
<title>Master branch</title>

<itemizedlist>
<listitem>
<para>
It should only see non-breaking commits that do not cause mass rebuilds.
</para>
</listitem>
</itemizedlist>
</section>

<listitem>
<para>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. <link xlink:href="http://hydra.nixos.org/jobset/nixpkgs/staging#tabs-evaluations">Keep an eye on the staging evaluations here</link>. If any fixes for staging happen to be already in master, then master can be merged into staging.</para>
</listitem>
<section>
<title>Staging branch</title>

<itemizedlist>
<listitem>
<para>
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.
<link xlink:href="http://comments.gmane.org/gmane.linux.distributions.nixos/13447">Read policy here</link>.
</para>
</listitem>
<listitem>
<para>
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.
<link xlink:href="http://hydra.nixos.org/jobset/nixpkgs/staging#tabs-evaluations">Keep an eye on the staging evaluations here</link>.
If any fixes for staging happen to be already in master, then master can
be merged into staging.
</para>
</listitem>
</itemizedlist>
</section>

<listitem>
<para>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.</para>
</listitem>
</itemizedlist>
<section>
<title>Stable release branches</title>

<itemizedlist>
<listitem>
<para>
If you're cherry-picking a commit to a stable release branch, always use
<command>git cherry-pick -xe</command> and ensure the message contains a
clear description about why this needs to be included in the stable
branch.
</para>
<para>An example of a cherry-picked commit would look like this:</para>
<screen>
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.
</screen>
</listitem>
</itemizedlist>
</section>

</section>
</chapter>
Expand Down