aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoe Perches <[email protected]>2011-12-09 14:12:00 -0800
committerGreg Kroah-Hartman <[email protected]>2011-12-12 14:14:31 -0800
commit2eb7f204db51969ea558802a6601d79c2fb273b9 (patch)
treecfe4008663ee94e362eb6a446bed4944e8b2ec52
parentbc7a2f3abc636d7cab84258a48e77b08fb5fd3d6 (diff)
Documentation: Update stable address
The Japanese/Korean/Chinese versions still need updating. Also, the stable kernel 2.6.x.y descriptions are out of date and should be updated as well. Signed-off-by: Joe Perches <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
-rw-r--r--Documentation/HOWTO4
-rw-r--r--Documentation/development-process/5.Posting8
2 files changed, 6 insertions, 6 deletions
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 81bc1a9ab9d8..f7ade3b3b40d 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -275,8 +275,8 @@ versions.
If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
kernel is the current stable kernel.
-2.6.x.y are maintained by the "stable" team <[email protected]>, and are
-released as needs dictate. The normal release period is approximately
+2.6.x.y are maintained by the "stable" team <[email protected]>, and
+are released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
instantly.
diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting
index 903a2546f138..8a48c9b62864 100644
--- a/Documentation/development-process/5.Posting
+++ b/Documentation/development-process/5.Posting
@@ -271,10 +271,10 @@ copies should go to:
the linux-kernel list.
- If you are fixing a bug, think about whether the fix should go into the
- next stable update. If so, [email protected] should get a copy of the
- patch. Also add a "Cc: [email protected]" to the tags within the patch
- itself; that will cause the stable team to get a notification when your
- fix goes into the mainline.
+ next stable update. If so, [email protected] should get a copy of
+ the patch. Also add a "Cc: [email protected]" to the tags within
+ the patch itself; that will cause the stable team to get a notification
+ when your fix goes into the mainline.
When selecting recipients for a patch, it is good to have an idea of who
you think will eventually accept the patch and get it merged. While it