README: added lots of info

header information, script information, contact information, and other
goodness.

diff --git a/README b/README
index 3451a5805685d1947d7a8eeae5502689ea73a5d5..48a63c8e83657cb28eee9ac80a62c8a815a1373f 100644 (file)
--- a/README
+++ b/README
@@ -1,7 +1,144 @@
 LTSI kernel tree
+================
+
+Table Of Contents
+=================
+
+       Introduction
+       Building the Tree
+       Patch Headers
+
+
+
+Introduction
+============
+
+This is the LTSI kernel tree.  It is developed as a set of patches, that
+apply to the specified kernel version.  The tree can be used directly as
+a quilt tree for development, or it can be exported as a git tree, a
+single compressed patch, or as an RPM source package that will
+successfully build in an OBS instance.
+
+For questions about the LTSI project, and how it operates, please see
+the documentation at http://somewhere.linuxfoundation.org
+
+For discussions about these patches, or anything else related to the
+LTSI project, please contact the partipitants at the
+ltsi@something.linuxfoundation.org mailing list.  Instructions on how to
+post to it can be found at http://SOMEWHERE.linuxfoundation.org
+
+
+Building the Tree
+=================
+
+The tree is maintained as a quilt tree of patches, all of which are
+applied in a sequence described in the file, 'series', to a specific
+kernel tree.
+
+The current version of the kernel tree that the sequence is to be
+applied to can be found in the file KERNEL_VERSION.
+
+The tree can be exported in a variety of different formats, to help you
+integrate it into your build system.  The currently supported formats
+are:
+       - quilt tree
+       - git tree
+       - single compressed patch
+       - OBS source repo
+
+Quilt Tree
+----------
+
+The tree is already in a quilt tree format, and can be developed in this
+manner.  It is recommended that you create a kernel tree based on the
+version described in the file KERNEL_VERSION and then change your
+QUILT_PATCHES environment variable to point to the location of this
+tree.  quilt will see the series file, and you can easily push and pop
+the various patches directly.
+
+
+Git Tree
+--------
+
+The tree can be exported as a git tree, based on the kernel.org upstream
+release described in the file KERNEL_VERSION.  To do this run the
+scripts/generate_git script.  For more details on the environment
+variables this script expects and how it works, please see the built in
+help in the script by running:
+       scripts/generate_git --help
+
+
+Single Compressed Patch
+-----------------------
+
+The tree can be exported as a compressed single patch, based on the
+kernel.org release described in the KERNEL_VERSION file.  To do this,
+run the scripts/generate_patch script.  For more details on the
+environment variables this script expects and how it works, please see
+the built in help in the script by running:
+       scripts/generate_patch --help
+
+
+OBS source
+----------
+
+The tree can be exported as a set of files that can be used as an OBS
+source package.  These files can then be used by OBS to generate both a
+kernel source and kernel binary package, for a specific configuration.
+To do this run the scripts/generate_obs script.  For more details on the
+environment variables this script expects and how it works, please see
+the built in help in the script by running:
+       scripts/generate_obs --help
+
+
+
+
+Patch Headers
+=============
+
+Each patch must have a RFC822-style header that at a minimum describes
+what the patch does, who wrote it, and who can be contacted for any
+questions about the patch.  The rules for patch headers are:
+
+ * Each patch must have a From: tag that identifies the author of the
+   patch.
+
+ * Each patch must have a Subject: tag that briefly describes what
+   the patch does.  A brief summary is it could show up in a change
+   log makes the most sense in most cases.
+
+ * The patch MUST include a Signed-off-by: address that identifies the
+   person or people who have reviewed the patch, and can be available if
+   there are any questions or problems about the patch.  For more
+   details on exactly what "Signed-off-by:" means, see the file,
+   Documentation/SubmittingPatches in the Linux kernel source tree.
+
+ * If the patch is already upstream, or has been submitted for inclusion
+   in the upstream kernel project, it must include a Patch-mainline: tag
+   that identifies where the patch came from (for backports from
+   mainline), or when it is expected to be added to mainline. The format
+   is Patch-mainline: <upstream version>
+   or Patch-mainline: Submitted <timestamp - destination>
+   or Patch-mainline: <guess followed by a question mark>
+   or Patch-mainline: Never <reason>
+
+   If applicable, please also include
+   Git-commit: <git hash> (there can be more than one if the patch is an
+   aggregate of multiple commits)
+
+   If the commit is from a maintainer repository or some other repository
+   that isn't Linus's:
+   Git-repo: <url to git repo>
+
+ * The patch header may (and often, should) include a more extensive
+   description of what the patch does, why, and how.  The idea is to
+   allow others to quickly identify what each patch is about, and to
+   give enough information for reviewing.
+
+
+----------------------
+
+Many thanks for the SUSE kernel team for their kernel patch rules, upon
+which these rules are closely based.
 
-Based on the 3.0.y stable kernel tree, this is a set of patches to apply
-to it.
 
-Any questions, please contact
-       Greg Kroah-Hartman <gregkh@linuxfoundation.org>