CONTRIBUTING

   1 Contributing to linux-libre-firmware
   2 ====================================
   3
   4 Basic Information
   5 -----------------
   6
   7 To report a bug or submit changes to this repository please send a
   8 message to the GNU Linux-libre mailing list:
   9 <https://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre>
  10
  11 -   Changes should be in the form of a patch generated by
  12     `git format-patch`.
  13
  14 -   A patch should address one, and only one, concern. For example, a
  15     bug fix.
  16
  17 -   Individual patches should be as small as possible, consisting of
  18     atomic changes. A single patch should neither be in a partial
  19     state, nor should it contain multiple unrelated changes that could
  20     be split into separate patches.
  21
  22 -   Don't add anything that can be regenerated from other things that
  23     were added.
  24
  25 -   When adding firmware your patch must update the WHENCE file to
  26     clearly state the license of the firmware and where it came from.
  27
  28 -   Your patch must also update the root level Makefile to build the
  29     firmware, as appropriate.
  30
  31 Git Commit Messages
  32 -------------------
  33
  34 -   Limit the subject to 50 characters.
  35
  36 -   Use proper capitalization and imperative mood in the subject.
  37
  38 -   Don't put a period at the end of the subject.
  39
  40 -   Small changes, like fixing a typo, can get by with only a subject.
  41     Larger changes should include a body too.
  42
  43 -   Use a blank line to separate the subject and body.
  44
  45 -   Use the body to explain the what and why of the change.
  46
  47 -   Wrap the body at 70 characters.
  48
  49 Development & Release Process
  50 -----------------------------
  51
  52 All development happens on the master branch. Releases are branched
  53 out from master in git.
  54
  55 The version number is incremented by 0.1 with every release. This
  56 increment happens regardless of the changes made. Anything can change
  57 between versions.
  58
  59 Every change, no matter how well-intentioned, introduces the potential
  60 for unexpected problems. For this reason changes on a release branch
  61 are more stringent, as opposed to the "anything can change"
  62 philosophy of the master branch.
  63
  64 There are only two types of changes that can be made to a release
  65 branch:
  66
  67 -   To fix a security vulnerability (a "security vulnerability" is
  68     defined as something for which a CVE ID exists.)
  69
  70 -   To fix a critical software bug (a "critical software bug" is
  71     defined as a build system or firmware failure.)
  72
  73 Updates for a released version involve adding a third point to the
  74 version number: 1.2.1, etc. and this third point is incremented by 1
  75 with every release (1.2.2, 1.2.3, etc.)
  76
  77 There is no timetable for releases: New versions are released when
  78 they're ready. Updates to release branches are made as needed.
  79
  80 Licensing
  81 ---------
  82
  83 You can redistribute and/or modify this file under the terms of the
  84 GNU General Public License as published by the Free Software
  85 Foundation, either version 3 of the License, or (at your option) any
  86 later version.