[PATCH] Documentation: Update stable address

[PATCH] Documentation: Update stable address

[Joe Perches]

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>
---
 Documentation/HOWTO                         |    4 ++--
 Documentation/development-process/5.Posting |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 81bc1a9..f7ade3b 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 <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.
diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting
index 903a254..8a48c9b 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, 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

Re: [PATCH] Documentation: Update stable address

[Arnd Bergmann]

On Wednesday 04 January 2012, Randy Dunlap wrote:
> > @@ -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.

Shouldn't the text get reworded as well to include the 3.x.y stable releases
and rename the 2.6.x.y releases to "longterm" instead of "stable"?

	Arnd

Re: [PATCH] Documentation: Update stable address

[Randy Dunlap]

On 12/09/2011 02:12 PM, Joe Perches wrote:
> 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>

Applied, thanks.

> ---
>  Documentation/HOWTO                         |    4 ++--
>  Documentation/development-process/5.Posting |    8 ++++----
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/HOWTO b/Documentation/HOWTO
> index 81bc1a9..f7ade3b 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 <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.
> diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting
> index 903a254..8a48c9b 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, 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
> 
> 
> 


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***