Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Rob Landley]

On 07/17/2013 08:34:08 AM, Paul Gortmaker wrote:

On 13-07-16 01:33 PM, Jonathan Corbet wrote:
> On Mon, 15 Jul 2013 19:34:44 -0400
> Paul Gortmaker  wrote:
>
>> The last mainline release of a v2.6.x kernel was back in May 2011.
>> Here we update references to be 3.x based, which also means  
updating

>> some dates and statistics.
>
> Ccing the author of the document never hurts :)

It might be worth sticking an entry in MAINTAINERS for that dir.
If one had asked me who wrote it, I probably would have recalled that
info, but instead I just out of habit ran get_maintainers...


I note that every file people stick a MAINTAINERS entry for in  
Documentation is one that I _don't_ bother with. Just FYI.


(Yes, 5 days behind on the list, but catching up...)

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Rob Landley]

On 07/17/2013 08:34:08 AM, Paul Gortmaker wrote:

On 13-07-16 01:33 PM, Jonathan Corbet wrote:
 On Mon, 15 Jul 2013 19:34:44 -0400
 Paul Gortmaker paul.gortma...@windriver.com wrote:

 The last mainline release of a v2.6.x kernel was back in May 2011.
 Here we update references to be 3.x based, which also means  
updating

 some dates and statistics.

 Ccing the author of the document never hurts :)

It might be worth sticking an entry in MAINTAINERS for that dir.
If one had asked me who wrote it, I probably would have recalled that
info, but instead I just out of habit ran get_maintainers...


I note that every file people stick a MAINTAINERS entry for in  
Documentation is one that I _don't_ bother with. Just FYI.


(Yes, 5 days behind on the list, but catching up...)

Rob--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

On 13-07-16 01:33 PM, Jonathan Corbet wrote:
> On Mon, 15 Jul 2013 19:34:44 -0400
> Paul Gortmaker  wrote:
> 
>> The last mainline release of a v2.6.x kernel was back in May 2011.
>> Here we update references to be 3.x based, which also means updating
>> some dates and statistics.
> 
> Ccing the author of the document never hurts :)

It might be worth sticking an entry in MAINTAINERS for that dir.
If one had asked me who wrote it, I probably would have recalled that
info, but instead I just out of habit ran get_maintainers...

> 
> I actually went through this exercise a while back, but somehow never got
> around to sending the changes out into the world.  Easily distracted, I
> guess.  Anyway, you can put my Acked-by on your changes if you like.

Thanks.

> 
>> On a similar note, I was thinking about the recent thread on linux-next
>> where we were indicating that people shouldn't rebase linux-next content
>> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
>> the linux-next content during the merge window.  There is no question
>> that the linux-next process is integral to the main flow of patches to
>> mainline, so I think Documentation/development-process/2.Process (the
>> same file) should also capture those points in the linux-next section.
>> Do you have some pre-canned text we can insert there, or should I draft
>> something up for you to review?
> 
> Seems useful, I could also try to help with this if you run out of steam.
> I'd be more inclined to put it into section 7, though, since it's the sort
> of thing early-stage developers don't normally need to worry about.

I'd agree with that; a pointer in section two where linux-next is 1st
mentioned can point to section7 where the advanced info is given.  

Paul.
--

> 
> Thanks,
> 
> jon
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

On 13-07-16 01:33 PM, Jonathan Corbet wrote:
 On Mon, 15 Jul 2013 19:34:44 -0400
 Paul Gortmaker paul.gortma...@windriver.com wrote:
 
 The last mainline release of a v2.6.x kernel was back in May 2011.
 Here we update references to be 3.x based, which also means updating
 some dates and statistics.
 
 Ccing the author of the document never hurts :)

It might be worth sticking an entry in MAINTAINERS for that dir.
If one had asked me who wrote it, I probably would have recalled that
info, but instead I just out of habit ran get_maintainers...

 
 I actually went through this exercise a while back, but somehow never got
 around to sending the changes out into the world.  Easily distracted, I
 guess.  Anyway, you can put my Acked-by on your changes if you like.

Thanks.

 
 On a similar note, I was thinking about the recent thread on linux-next
 where we were indicating that people shouldn't rebase linux-next content
 on a whim, and that new devel (vs. bugfix) content shouldn't appear in
 the linux-next content during the merge window.  There is no question
 that the linux-next process is integral to the main flow of patches to
 mainline, so I think Documentation/development-process/2.Process (the
 same file) should also capture those points in the linux-next section.
 Do you have some pre-canned text we can insert there, or should I draft
 something up for you to review?
 
 Seems useful, I could also try to help with this if you run out of steam.
 I'd be more inclined to put it into section 7, though, since it's the sort
 of thing early-stage developers don't normally need to worry about.

I'd agree with that; a pointer in section two where linux-next is 1st
mentioned can point to section7 where the advanced info is given.  

Paul.
--

 
 Thanks,
 
 jon
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Jonathan Corbet]

On Mon, 15 Jul 2013 19:34:44 -0400
Paul Gortmaker  wrote:

> The last mainline release of a v2.6.x kernel was back in May 2011.
> Here we update references to be 3.x based, which also means updating
> some dates and statistics.

Ccing the author of the document never hurts :)

I actually went through this exercise a while back, but somehow never got
around to sending the changes out into the world.  Easily distracted, I
guess.  Anyway, you can put my Acked-by on your changes if you like.

> On a similar note, I was thinking about the recent thread on linux-next
> where we were indicating that people shouldn't rebase linux-next content
> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> the linux-next content during the merge window.  There is no question
> that the linux-next process is integral to the main flow of patches to
> mainline, so I think Documentation/development-process/2.Process (the
> same file) should also capture those points in the linux-next section.
> Do you have some pre-canned text we can insert there, or should I draft
> something up for you to review?

Seems useful, I could also try to help with this if you run out of steam.
I'd be more inclined to put it into section 7, though, since it's the sort
of thing early-stage developers don't normally need to worry about.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Jonathan Corbet]

On Mon, 15 Jul 2013 19:34:44 -0400
Paul Gortmaker paul.gortma...@windriver.com wrote:

 The last mainline release of a v2.6.x kernel was back in May 2011.
 Here we update references to be 3.x based, which also means updating
 some dates and statistics.

Ccing the author of the document never hurts :)

I actually went through this exercise a while back, but somehow never got
around to sending the changes out into the world.  Easily distracted, I
guess.  Anyway, you can put my Acked-by on your changes if you like.

 On a similar note, I was thinking about the recent thread on linux-next
 where we were indicating that people shouldn't rebase linux-next content
 on a whim, and that new devel (vs. bugfix) content shouldn't appear in
 the linux-next content during the merge window.  There is no question
 that the linux-next process is integral to the main flow of patches to
 mainline, so I think Documentation/development-process/2.Process (the
 same file) should also capture those points in the linux-next section.
 Do you have some pre-canned text we can insert there, or should I draft
 something up for you to review?

Seems useful, I could also try to help with this if you run out of steam.
I'd be more inclined to put it into section 7, though, since it's the sort
of thing early-stage developers don't normally need to worry about.

Thanks,

jon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

[Re: [PATCH] Documentation: update references to v2.6.x in development-process] 
On 16/07/2013 (Tue 13:50) Stephen Rothwell wrote:

> Hi Paul,
> 
> On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker 
>  wrote:
> >
> > On a similar note, I was thinking about the recent thread on linux-next
> > where we were indicating that people shouldn't rebase linux-next content
> > on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> > the linux-next content during the merge window.  There is no question
> > that the linux-next process is integral to the main flow of patches to
> > mainline, so I think Documentation/development-process/2.Process (the
> > same file) should also capture those points in the linux-next section.
> > Do you have some pre-canned text we can insert there, or should I draft
> > something up for you to review?
> 
> The latter would be certainly easier for me :-)  If that is not easy, let
> me know and I will write something (even without swearing ;-)).

I'll do something for the latter, but I can't promise to refrain from
swearing...  ;-)

Thanks,
Paul.
--

> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Ben Hutchings]

On Mon, 2013-07-15 at 19:34 -0400, Paul Gortmaker wrote:
[...] 
>  Some kernels are designated "long term" kernels; they will receive support
>  for a longer period.  As of this writing, the current long term kernels
>  and their maintainers are:
>  
> - 2.6.27  Willy Tarreau   (Deep-frozen stable kernel)
> - 2.6.32  Greg Kroah-Hartman
> - 2.6.35  Andi Kleen  (Embedded flag kernel)
> + 2.6.32  Willy Tarreau
> + 3.0 Greg Kroah-Hartman
> + 3.2 Ben Hutchings
> + 3.4 Greg Kroah-Hartman
[...]

You could also link to  here.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Stephen Rothwell]

Hi Paul,

On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker 
 wrote:
>
> On a similar note, I was thinking about the recent thread on linux-next
> where we were indicating that people shouldn't rebase linux-next content
> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> the linux-next content during the merge window.  There is no question
> that the linux-next process is integral to the main flow of patches to
> mainline, so I think Documentation/development-process/2.Process (the
> same file) should also capture those points in the linux-next section.
> Do you have some pre-canned text we can insert there, or should I draft
> something up for you to review?

The latter would be certainly easier for me :-)  If that is not easy, let
me know and I will write something (even without swearing ;-)).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpNaByfj4AmS.pgp
Description: PGP signature

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

[Re: [PATCH] Documentation: update references to v2.6.x in development-process] 
On 16/07/2013 (Tue 10:15) Stephen Rothwell wrote:

> Hi Paul,
> 
> Good work!
> 
> On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker 
>  wrote:
> >
> >  Linux-next trees are announced on the linux-kernel and linux-next mailing
> >  lists when they are assembled; they can be downloaded from:
> >  
> > -   http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/
> > +   https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
> 
> Maybe:
> 
> " git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 
> Or as patches relative to Linus' latest -rc or releases from:
> 
>   https://www.kernel.org/pub/linux/kernel/next/
> 
> Or viewed online at:
> 
>   https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
> "
> 
> Or maybe that is a bit verbose.

Probably no harm in it.  I'd cc'd you and akpm for exactly that reason;
I wasn't sure I'd updated to the authoratative source.  I'll fold that
into a v2 once there has been a chance for other feedback to come in.

On a similar note, I was thinking about the recent thread on linux-next
where we were indicating that people shouldn't rebase linux-next content
on a whim, and that new devel (vs. bugfix) content shouldn't appear in
the linux-next content during the merge window.  There is no question
that the linux-next process is integral to the main flow of patches to
mainline, so I think Documentation/development-process/2.Process (the
same file) should also capture those points in the linux-next section.
Do you have some pre-canned text we can insert there, or should I draft
something up for you to review?

Thanks,
Paul.
--

> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Stephen Rothwell]

Hi Paul,

Good work!

On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker 
 wrote:
>
>  Linux-next trees are announced on the linux-kernel and linux-next mailing
>  lists when they are assembled; they can be downloaded from:
>  
> - http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/
> + https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/

Maybe:

"   git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Or as patches relative to Linus' latest -rc or releases from:

https://www.kernel.org/pub/linux/kernel/next/

Or viewed online at:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
"

Or maybe that is a bit verbose.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpwYKXIgbpJj.pgp
Description: PGP signature

[PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

The last mainline release of a v2.6.x kernel was back in May 2011.
Here we update references to be 3.x based, which also means updating
some dates and statistics.

Also update information pertaining to longterm releases.  Here I have
intentionally left out any mention of the v2.6.34.x longterm, since I
will EOL it before this patch makes it in the v3.12 kernel anyway.

Finally, update the links to mmotm and linux-next trees, as neither of
them worked and pre-dated the kernel.org server rebuilds.

Cc: Rob Landley 
Cc: Willy Tarreau 
Cc: Ben Hutchings 
Cc: Greg Kroah-Hartman 
Cc: Andrew Morton 
Cc: Stephen Rothwell 
Signed-off-by: Paul Gortmaker 

diff --git a/Documentation/development-process/2.Process 
b/Documentation/development-process/2.Process
index 4823577..0c943a1 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -14,16 +14,16 @@ The kernel developers use a loosely time-based release 
process, with a new
 major kernel release happening every two or three months.  The recent
 release history looks like this:
 
-   2.6.38  March 14, 2011
-   2.6.37  January 4, 2011
-   2.6.36  October 20, 2010
-   2.6.35  August 1, 2010
-   2.6.34  May 15, 2010
-   2.6.33  February 24, 2010
-
-Every 2.6.x release is a major kernel release with new features, internal
-API changes, and more.  A typical 2.6 release can contain nearly 10,000
-changesets with changes to several hundred thousand lines of code.  2.6 is
+   3.10June 30, 2013
+   3.9 April 28, 2013
+   3.8 February 18, 2013
+   3.7 December 10, 2012
+   3.6 September 30, 2012
+   3.5 July 21, 2012
+
+Every 3.x release is a major kernel release with new features, internal
+API changes, and more.  A typical 3.x release can contain over 10,000
+changesets with changes to several hundred thousand lines of code.  3.x is
 thus the leading edge of Linux kernel development; the kernel uses a
 rolling development model which is continually integrating major changes.
 
@@ -43,9 +43,9 @@ detail later on).
 
 The merge window lasts for approximately two weeks.  At the end of this
 time, Linus Torvalds will declare that the window is closed and release the
-first of the "rc" kernels.  For the kernel which is destined to be 2.6.40,
+first of the "rc" kernels.  For the kernel which is destined to be 3.12,
 for example, the release which happens at the end of the merge window will
-be called 2.6.40-rc1.  The -rc1 release is the signal that the time to
+be tagged v3.12-rc1.  The -rc1 release is the signal that the time to
 merge new features has passed, and that the time to stabilize the next
 kernel has begun.
 
@@ -62,22 +62,21 @@ add at any time).
 As fixes make their way into the mainline, the patch rate will slow over
 time.  Linus releases new -rc kernels about once a week; a normal series
 will get up to somewhere between -rc6 and -rc9 before the kernel is
-considered to be sufficiently stable and the final 2.6.x release is made.
+considered to be sufficiently stable and the final 3.x release is made.
 At that point the whole process starts over again.
 
-As an example, here is how the 2.6.38 development cycle went (all dates in
-2011):
+As an example, here is how the 3.10 development cycle went (all dates in
+2013):
 
-   January 4   2.6.37 stable release
-   January 18  2.6.38-rc1, merge window closes
-   January 21  2.6.38-rc2
-   February 1  2.6.38-rc3
-   February 7  2.6.38-rc4
-   February 15 2.6.38-rc5
-   February 21 2.6.38-rc6
-   March 1 2.6.38-rc7
-   March 7 2.6.38-rc8
-   March 142.6.38 stable release
+   April 283.9 stable release
+   May 11  3.10-rc1, merge window closes
+   May 20  3.10-rc2
+   May 26  3.10-rc3
+   June 2  3.10-rc4
+   June 8  3.10-rc5
+   June 15 3.10-rc6
+   June 22 3.10-rc7
+   June 30 3.10 stable release
 
 How do the developers decide when to close the development cycle and create
 the stable release?  The most significant metric used is the list of
@@ -92,34 +91,41 @@ release is made.  In the real world, this kind of 
perfection is hard to
 achieve; there are just too many variables in a project of this size.
 There comes a point where delaying the final release just makes the problem
 worse; the pile of changes waiting for the next merge window will grow
-larger, creating even more regressions the next time around.  So most 2.6.x
+larger, creating even more regressions the next time around.  So most 3.x
 kernels go out with a handful of known regressions though, hopefully, none
 of them are serious.
 
 Once a stable release is made, its ongoing maintenance is passed off to the
 "stable team," currently consisting of Greg Kroah-Hartman.  The stable team
-will release occasional updates to the stable 

[PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

The last mainline release of a v2.6.x kernel was back in May 2011.
Here we update references to be 3.x based, which also means updating
some dates and statistics.

Also update information pertaining to longterm releases.  Here I have
intentionally left out any mention of the v2.6.34.x longterm, since I
will EOL it before this patch makes it in the v3.12 kernel anyway.

Finally, update the links to mmotm and linux-next trees, as neither of
them worked and pre-dated the kernel.org server rebuilds.

Cc: Rob Landley r...@landley.net
Cc: Willy Tarreau w...@1wt.eu
Cc: Ben Hutchings b...@decadent.org.uk
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com

diff --git a/Documentation/development-process/2.Process 
b/Documentation/development-process/2.Process
index 4823577..0c943a1 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -14,16 +14,16 @@ The kernel developers use a loosely time-based release 
process, with a new
 major kernel release happening every two or three months.  The recent
 release history looks like this:
 
-   2.6.38  March 14, 2011
-   2.6.37  January 4, 2011
-   2.6.36  October 20, 2010
-   2.6.35  August 1, 2010
-   2.6.34  May 15, 2010
-   2.6.33  February 24, 2010
-
-Every 2.6.x release is a major kernel release with new features, internal
-API changes, and more.  A typical 2.6 release can contain nearly 10,000
-changesets with changes to several hundred thousand lines of code.  2.6 is
+   3.10June 30, 2013
+   3.9 April 28, 2013
+   3.8 February 18, 2013
+   3.7 December 10, 2012
+   3.6 September 30, 2012
+   3.5 July 21, 2012
+
+Every 3.x release is a major kernel release with new features, internal
+API changes, and more.  A typical 3.x release can contain over 10,000
+changesets with changes to several hundred thousand lines of code.  3.x is
 thus the leading edge of Linux kernel development; the kernel uses a
 rolling development model which is continually integrating major changes.
 
@@ -43,9 +43,9 @@ detail later on).
 
 The merge window lasts for approximately two weeks.  At the end of this
 time, Linus Torvalds will declare that the window is closed and release the
-first of the rc kernels.  For the kernel which is destined to be 2.6.40,
+first of the rc kernels.  For the kernel which is destined to be 3.12,
 for example, the release which happens at the end of the merge window will
-be called 2.6.40-rc1.  The -rc1 release is the signal that the time to
+be tagged v3.12-rc1.  The -rc1 release is the signal that the time to
 merge new features has passed, and that the time to stabilize the next
 kernel has begun.
 
@@ -62,22 +62,21 @@ add at any time).
 As fixes make their way into the mainline, the patch rate will slow over
 time.  Linus releases new -rc kernels about once a week; a normal series
 will get up to somewhere between -rc6 and -rc9 before the kernel is
-considered to be sufficiently stable and the final 2.6.x release is made.
+considered to be sufficiently stable and the final 3.x release is made.
 At that point the whole process starts over again.
 
-As an example, here is how the 2.6.38 development cycle went (all dates in
-2011):
+As an example, here is how the 3.10 development cycle went (all dates in
+2013):
 
-   January 4   2.6.37 stable release
-   January 18  2.6.38-rc1, merge window closes
-   January 21  2.6.38-rc2
-   February 1  2.6.38-rc3
-   February 7  2.6.38-rc4
-   February 15 2.6.38-rc5
-   February 21 2.6.38-rc6
-   March 1 2.6.38-rc7
-   March 7 2.6.38-rc8
-   March 142.6.38 stable release
+   April 283.9 stable release
+   May 11  3.10-rc1, merge window closes
+   May 20  3.10-rc2
+   May 26  3.10-rc3
+   June 2  3.10-rc4
+   June 8  3.10-rc5
+   June 15 3.10-rc6
+   June 22 3.10-rc7
+   June 30 3.10 stable release
 
 How do the developers decide when to close the development cycle and create
 the stable release?  The most significant metric used is the list of
@@ -92,34 +91,41 @@ release is made.  In the real world, this kind of 
perfection is hard to
 achieve; there are just too many variables in a project of this size.
 There comes a point where delaying the final release just makes the problem
 worse; the pile of changes waiting for the next merge window will grow
-larger, creating even more regressions the next time around.  So most 2.6.x
+larger, creating even more regressions the next time around.  So most 3.x
 kernels go out with a handful of known regressions though, hopefully, none
 of them are serious.
 
 Once a stable release is made, its ongoing maintenance is 

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Stephen Rothwell]

Hi Paul,

Good work!

On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker 
paul.gortma...@windriver.com wrote:

  Linux-next trees are announced on the linux-kernel and linux-next mailing
  lists when they are assembled; they can be downloaded from:
  
 - http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/
 + https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/

Maybe:

   git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Or as patches relative to Linus' latest -rc or releases from:

https://www.kernel.org/pub/linux/kernel/next/

Or viewed online at:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/


Or maybe that is a bit verbose.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpwYKXIgbpJj.pgp
Description: PGP signature

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

[Re: [PATCH] Documentation: update references to v2.6.x in development-process] 
On 16/07/2013 (Tue 10:15) Stephen Rothwell wrote:

 Hi Paul,
 
 Good work!
 
 On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker 
 paul.gortma...@windriver.com wrote:
 
   Linux-next trees are announced on the linux-kernel and linux-next mailing
   lists when they are assembled; they can be downloaded from:
   
  -   http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/
  +   https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
 
 Maybe:
 
  git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
 
 Or as patches relative to Linus' latest -rc or releases from:
 
   https://www.kernel.org/pub/linux/kernel/next/
 
 Or viewed online at:
 
   https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
 
 
 Or maybe that is a bit verbose.

Probably no harm in it.  I'd cc'd you and akpm for exactly that reason;
I wasn't sure I'd updated to the authoratative source.  I'll fold that
into a v2 once there has been a chance for other feedback to come in.

On a similar note, I was thinking about the recent thread on linux-next
where we were indicating that people shouldn't rebase linux-next content
on a whim, and that new devel (vs. bugfix) content shouldn't appear in
the linux-next content during the merge window.  There is no question
that the linux-next process is integral to the main flow of patches to
mainline, so I think Documentation/development-process/2.Process (the
same file) should also capture those points in the linux-next section.
Do you have some pre-canned text we can insert there, or should I draft
something up for you to review?

Thanks,
Paul.
--

 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Stephen Rothwell]

Hi Paul,

On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker 
paul.gortma...@windriver.com wrote:

 On a similar note, I was thinking about the recent thread on linux-next
 where we were indicating that people shouldn't rebase linux-next content
 on a whim, and that new devel (vs. bugfix) content shouldn't appear in
 the linux-next content during the merge window.  There is no question
 that the linux-next process is integral to the main flow of patches to
 mainline, so I think Documentation/development-process/2.Process (the
 same file) should also capture those points in the linux-next section.
 Do you have some pre-canned text we can insert there, or should I draft
 something up for you to review?

The latter would be certainly easier for me :-)  If that is not easy, let
me know and I will write something (even without swearing ;-)).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpNaByfj4AmS.pgp
Description: PGP signature

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Ben Hutchings]

On Mon, 2013-07-15 at 19:34 -0400, Paul Gortmaker wrote:
[...] 
  Some kernels are designated long term kernels; they will receive support
  for a longer period.  As of this writing, the current long term kernels
  and their maintainers are:
  
 - 2.6.27  Willy Tarreau   (Deep-frozen stable kernel)
 - 2.6.32  Greg Kroah-Hartman
 - 2.6.35  Andi Kleen  (Embedded flag kernel)
 + 2.6.32  Willy Tarreau
 + 3.0 Greg Kroah-Hartman
 + 3.2 Ben Hutchings
 + 3.4 Greg Kroah-Hartman
[...]

You could also link to https://www.kernel.org/releases.html here.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

[Re: [PATCH] Documentation: update references to v2.6.x in development-process] 
On 16/07/2013 (Tue 13:50) Stephen Rothwell wrote:

 Hi Paul,
 
 On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker 
 paul.gortma...@windriver.com wrote:
 
  On a similar note, I was thinking about the recent thread on linux-next
  where we were indicating that people shouldn't rebase linux-next content
  on a whim, and that new devel (vs. bugfix) content shouldn't appear in
  the linux-next content during the merge window.  There is no question
  that the linux-next process is integral to the main flow of patches to
  mainline, so I think Documentation/development-process/2.Process (the
  same file) should also capture those points in the linux-next section.
  Do you have some pre-canned text we can insert there, or should I draft
  something up for you to review?
 
 The latter would be certainly easier for me :-)  If that is not easy, let
 me know and I will write something (even without swearing ;-)).

I'll do something for the latter, but I can't promise to refrain from
swearing...  ;-)

Thanks,
Paul.
--

 
 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/