[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120110215021.072077914@clark.kroah.org>
Date:	Tue, 10 Jan 2012 13:48:12 -0800
From:	Greg KH <gregkh@...e.de>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Cc:	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Joe Perches <joe@...ches.com>
Subject: [02/42] Documentation: Update stable address
3.1-stable review patch.  If anyone has any objections, please let me know.
------------------
From: Joe Perches <joe@...ches.com>
commit 2eb7f204db51969ea558802a6601d79c2fb273b9 upstream.
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 <joe@...ches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
 Documentation/HOWTO                         |    4 ++--
 Documentation/development-process/5.Posting |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)
--- 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 <stable@...nel.org>, and are
-released as needs dictate.  The normal release period is approximately 
+2.6.x.y are maintained by the "stable" team <stable@...r.kernel.org>, 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.
--- 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, stable@...nel.org should get a copy of the
-   patch.  Also add a "Cc: stable@...nel.org" 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, stable@...r.kernel.org should get a copy of
+   the patch.  Also add a "Cc: stable@...r.kernel.org" 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Powered by blists - more mailing lists
 
