Patchwork [5/6] CheckInTests: Bring up to date with recent changes

mail settings
Submitter Chuck Lever
Date Jan. 20, 2012, 9:22 p.m.
Message ID <>
Download mbox | patch
Permalink /patch/137116/
State Accepted
Headers show


Chuck Lever - Jan. 20, 2012, 9:22 p.m.
Signed-off-by: Chuck Lever <>

 doc/CheckInTests |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)


diff --git a/doc/CheckInTests b/doc/CheckInTests
index 550e6d5..d8f2c17 100644
--- a/doc/CheckInTests
+++ b/doc/CheckInTests
@@ -63,16 +63,21 @@  Especially:
 See also Documentation/CodingStyle in the Linux kernel source tree.
+Please ensure you have the right to submit the patches you send.  If
+you create changes at work, your employer may own the patch.
+Submitted patches fall under the GPLv2 once they are merged.
 This is an open source project, so design and code review are a key part
 of the development process.  Patches are posted for review on
+<> and can be tracked via a patchwork
+repository at .
 Before commits become a permanent part of the source control history,
-time-limited review is performed on the mailing list.
+time-limited review is performed on the above mailing list.
 Per-commit acceptance tests
@@ -93,6 +98,9 @@  bisecting to be useful.
 Note that to preserve bisectability, the tree MUST build after each
+Try to maintain documentation coherency with code.  Check code against
+man pages and the INSTALL and README documents.
 At some point, we'd like:
  1.  Automated checking of coding style and white space
  2.  fortify, sparse, or splint testing
@@ -113,6 +121,9 @@  Per-release
  While we are in alpha, that last rule may be bent somewhat.
+ Maintenance releases are generally for bug fixes and security patches.
+ New feature development occurs in major and minor releases.
  Release candidate:
  One or more release candidates will be provided before each minor and