Firstly, I'd like to thank Greg for all the past work he's done on
juggling all these different stable releases - many people have
reaped the benefits of them for quite some time, and it only makes
sense to spread the loading around as it has grown significantly.

With that in mind, it is our intention to also maintain a 2.6.34
longterm tree.  Jason and I work at Wind River, which already has
released products based on v2.6.34, and as such it only makes sense
to have a public long-term tree that others who are also based on
2.6.34 can make use of.

I've already done an end-to-end audit of the current 2.6.32 longterm
stable release, and used the list of these already "approved for stable"
patches on v2.6.32 to identify 260 upstream commits that are applicable,
but not yet present in the last 2.6.34.7 stable release.

A candidate tree for 2.6.34.8 with the above 260 commits applied to
it is available now for review/testing at:

   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-2.6.34.y.git

Note that there are no additional "non-stable" commits applied to this
tree.  It is purely commits that are already in use in a stable release.
The next step will be to audit the 35-stable for appropriate content.

This tree is currently undergoing internal testing at WR on various
x86[64], ARM, MIPS and PowerPC targets, but of course any additional
testing and feedback is most welcome.  If anyone is interested in the
audit data, I can send folks details on that too.

Just as with Andi's longterm tree, the final details of where these
will be finally located on kernel.org and so forth remains to be worked
out and will be announced at a later date as things are finalized.

Paul.
--

[ message continues ]

Other than Wind River, what other distros/userbases are using .34 as a
platform for their products?

And how long do you expect to be maintaining this .34 branch for?

curious,

greg k-h
--

[ message continues ]

Well, since we create more of a distro builder, than a distro itself,
anyone who uses WR to in turn create a distro for their own hardware or
product will of course be using 2.6.34.  The Yocto project is currently
using the 2.6.34 kernel and I'm sure there are others I'm not

The expectation is that maintenance will be ongoing for years, since
we'll largely be needing to do that work anyway.  I plan to follow your
lead on how you handled .27 -- i.e. the "early" releases will possibly
be rich with content, but as it gets to be closer to EOL (i.e. on the
order of 10 releases removed from current), then it will only be the key
CVE-like fixes and similar which will be added.

--

[ message continues ]

I thought Yocto was going to be using .35, hence Andi and Tim's work to
get that one "longterm"?


That sounds very reasonable.

If there's anything I can do to help out, let me know.

thanks,

greg k-h
--

[ message continues ]

There was some slight confusion at the plumbers conference, but Paul
is correct, the kernel that accompanied yocto 0.9 was 2.6.34 based, and

Also fine with me, just thought I'd take the chance to clarify.

Cheers,




-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
--

[ message continues ]

I am not sure companies/platforms(Sony, Google, Meego, and Linaro)
mentioned below article really made a promise to produce product.
Article said, they decided 2.6.35 with flag version.
If it were real, I think flag version impact would be big on embedded
system(To be honest, alone android is enough big)
Cced Tim.

http://lwn.net/Articles/413341/

Thanks for you effort, Good Luck, Paul. :)
-- 
Kind regards,
Minchan Kim
--

[ message continues ]

Oops, I realized Andi maintains 2.6.35-longterm.
It's good to hear.

Sorry for the noise.



-- 
Kind regards,
Minchan Kim
--

[ message continues ]

That's great, but you really don't want to keep the patches in a
"combined" git tree like this for development and review.  What happens
if someone says "patch 121 needs to be removed"?

I recommend using quilt like we have been for the stable tree for the
past 5+ years as it handles situations like this very well.

Other than that, good luck with this, it's a lot of work :)

greg k-h
--

[ message continues ]

It was my intention to also create a git repo of patches, but since I've
found myself using quilt less and less in favour of just using git
directly, it wasn't a natural byproduct of my work so far. 

Fortunately its easy to dump patches out into a repo of patches suitable
for quilt, so there is one now, and it makes a good place to put that
audit data relating to this that I'd sent you a couple weeks ago.


Thanks!

--

[ message continues ]