From: Jason Self <j@jxself.org>
Date: Sun, 20 May 2018 15:18:56 +0000 (-0700)
Subject: Add initial contributing guide
X-Git-Tag: v1.3~24
X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=a5d2270fd74012fee1516f454deb034c120d45cc;p=librecmc%2Flinux-libre-firmware.git

Add initial contributing guide
---

diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644
index 0000000..13e5e87
--- /dev/null
+++ b/CONTRIBUTING
@@ -0,0 +1,65 @@
+Contributing to linux-libre-firmware
+====================================
+
+Basic Information
+-----------------
+
+To report a bug or submit changes to this repository please send a
+patch to the GNU Linux-libre mailing list:
+<https://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre>
+
+-   Changes should be in the form of a patch generated by
+    `git format-patch`. Email those to the mailing list for review.
+
+-   A patch should address one, and only one, concern. For example, a
+    bug fix.
+
+-   Individual patches should be as small as possible, consisting of
+    atomic changes. A single patch should neither be in a partial
+    state, nor should it contain multiple unrelated changes that could
+    be split into separate patches.
+
+-   Don't add anything that can be regenerated from other things that
+    were added.
+
+-   When adding firmware your patch must update the WHENCE file to
+    clearly state the license of the firmware and where it came from.
+
+-   Your patch must also update the root level Makefile to build the
+    firmware, as appropriate.
+
+Development & Release Process
+-----------------------------
+
+All development happens on the master branch. Releases are branched
+out from master in git.
+
+The version number is incremented by 0.1 with every release. This
+increment happens regardless of the changes made. Anything can change
+between versions.
+
+Every change, no matter how well-intentioned, introduces the potential
+for unexpected problems. For this reason changes on a release branch
+are more stringent, as opposed to "anything can change" philosophy of
+the master branch.
+
+There are only two types of changes that can be made to a release
+branch:
+
+-   To fix a security vulnerability (a "security vulnerability" is
+    defined as something for which a CVE ID exists.)
+
+-   To fix a critical software bug (a "critical software bug" is
+    defined as a build system or firmware failure.)
+
+Updates for a released version involve adding a third point to the
+version number: 1.2.1, etc. and this third point is incremented by 1
+with every release (1.2.2, 1.2.3, etc.)
+
+Licensing
+---------
+
+You can redistribute it and/or modify this file under the terms of the
+GNU General Public License as published by the Free Software
+Foundation, either version 3 of the License, or (at your option) any
+later version.