From a5d2270fd74012fee1516f454deb034c120d45cc Mon Sep 17 00:00:00 2001 From: Jason Self Date: Sun, 20 May 2018 08:18:56 -0700 Subject: [PATCH] Add initial contributing guide --- CONTRIBUTING | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 CONTRIBUTING 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: + + +- 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. -- 2.31.1