Contributing to linux-libre-firmware ==================================== Basic Information ----------------- To report a bug or submit changes to this repository please send a message to the GNU Linux-libre mailing list: - Changes should be in the form of a patch generated by `git format-patch`. - 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. Git Commit Messages ------------------- - Limit the subject to 50 characters. - Use proper capitalization and imperative mood in the subject. - Don't put a period at the end of the subject. - Small changes, like fixing a typo, can get by with only a subject. Larger changes should include a body too. - Use a blank line to separate the subject and body. - Use the body to explain the what and why of the change. - Wrap the body at 70 characters. 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 the "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.) There is no timetable for releases: New versions are released when they're ready. Updates to release branches are made as needed. Licensing --------- You can redistribute 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.