Documentation: Update stable address
authorJoe Perches <joe@perches.com>
Fri, 9 Dec 2011 22:12:00 +0000 (14:12 -0800)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 12 Dec 2011 22:14:31 +0000 (14:14 -0800)
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@perches.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Documentation/HOWTO
Documentation/development-process/5.Posting

index 81bc1a9ab9d8fa1357fcbb56268156786f741287..f7ade3b3b40ddd9a6cdda84f2a26be624e7e664f 100644 (file)
@@ -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@kernel.org>, and are
-released as needs dictate.  The normal release period is approximately 
+2.6.x.y are maintained by the "stable" team <stable@vger.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.
index 903a2546f13890b17d309554f3cbda69c2ee9ade..8a48c9b62864ed464f18fb0d93c16102f18ebc2f 100644 (file)
@@ -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@kernel.org should get a copy of the
-   patch.  Also add a "Cc: stable@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.
+   next stable update.  If so, stable@vger.kernel.org should get a copy of
+   the patch.  Also add a "Cc: stable@vger.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