Bug 2396

I was hoping to pick up LTSI support and sync on 3.4. I'll contact greg again to
see what his plan are in this area.

Do you mean 3.0-stable -rt for the last part ? I'm thinking you do.

For the 3.0 tree, since we've had it out for a while, I'll have to fork
the repository and rebase on top of LTSI and move all old releases to the
3.0.x tree that I created for linux-yocto-3.0-1.1.x. But there's a complication.
The 3.0 tree that was updated for 1.2 has fixes that shouldn't really go
back to 1.1.x (if there are anymore), so we either stack them on there and
do no more 1.1.x updates and re-do the 3.0 tree to be on top of LTSI.

We can easily get into tree explosion in a scenario like this. 

There is an option to change branch names, and stack all of the old releases
branches into a single -stable tree. That prevents tree count explosion. 

Alternatively, we wait until the next LTSI and build on top of it from
the beginning and it won't cause a problem like this.

(In reply to comment #1)
> I was hoping to pick up LTSI support and sync on 3.4. I'll contact greg
> again to
> see what his plan are in this area.
> 
> Do you mean 3.0-stable -rt for the last part ? I'm thinking you do.

Yes, oops. This one specifically:
http://kernel.org/pub/linux/kernel/projects/rt/3.0/README

There is also one of these for 3.2 incidentally. Note that they are guranteed not to rebase!

> 
> For the 3.0 tree, since we've had it out for a while, I'll have to fork
> the repository and rebase on top of LTSI and move all old releases to the
> 3.0.x tree that I created for linux-yocto-3.0-1.1.x. But there's a
> complication.
> The 3.0 tree that was updated for 1.2 has fixes that shouldn't really go
> back to 1.1.x (if there are anymore), so we either stack them on there and
> do no more 1.1.x updates and re-do the 3.0 tree to be on top of LTSI.
> 
> We can easily get into tree explosion in a scenario like this. 
> 
> There is an option to change branch names, and stack all of the old releases
> branches into a single -stable tree. That prevents tree count explosion. 
> 
> Alternatively, we wait until the next LTSI and build on top of it from
> the beginning and it won't cause a problem like this.

That does get messy. And of course changing this tree would result in changing the kernel for 1.2, which I don't want to do. However, 3.4 will be out very soon, and it seems to me we may want to have a linux-yocto-3.5 for the 1.3 release. I'd really rather not have both. At the same time, we are behind here and we need an LTSI kernel. At this point, I'm thinking we should release a 3.4-LTSI kernel for 1.3. This is consistent with the goals of 1.3 (fix, polish, etc.).

The more I think on it... the more I like the idea of a 3.4 LTSI only for 1.3. It would give us extra time to get the policy and config refactoring and the various tooling items done WELL and RIGHT. We would need to confirm with Greg that this aligns with his goals.

Thoughts?

(In reply to comment #2)
> (In reply to comment #1)
> > I was hoping to pick up LTSI support and sync on 3.4. I'll contact greg
> > again to
> > see what his plan are in this area.
> > 
> > Do you mean 3.0-stable -rt for the last part ? I'm thinking you do.
> 
> Yes, oops. This one specifically:
> http://kernel.org/pub/linux/kernel/projects/rt/3.0/README
> 
> There is also one of these for 3.2 incidentally. Note that they are
> guranteed not to rebase!

perfect. We agree there.

> 
> > 
> > For the 3.0 tree, since we've had it out for a while, I'll have to fork
> > the repository and rebase on top of LTSI and move all old releases to the
> > 3.0.x tree that I created for linux-yocto-3.0-1.1.x. But there's a
> > complication.
> > The 3.0 tree that was updated for 1.2 has fixes that shouldn't really go
> > back to 1.1.x (if there are anymore), so we either stack them on there and
> > do no more 1.1.x updates and re-do the 3.0 tree to be on top of LTSI.
> > 
> > We can easily get into tree explosion in a scenario like this. 
> > 
> > There is an option to change branch names, and stack all of the old releases
> > branches into a single -stable tree. That prevents tree count explosion. 
> > 
> > Alternatively, we wait until the next LTSI and build on top of it from
> > the beginning and it won't cause a problem like this.
> 
> That does get messy. And of course changing this tree would result in
> changing the kernel for 1.2, which I don't want to do. However, 3.4 will be
> out very soon, and it seems to me we may want to have a linux-yocto-3.5 for
> the 1.3 release. I'd really rather not have both. At the same time, we are
> behind here and we need an LTSI kernel. At this point, I'm thinking we
> should release a 3.4-LTSI kernel for 1.3. This is consistent with the goals
> of 1.3 (fix, polish, etc.).

This was the rough plan, to take a stutter step in 1.3 and align with
LTSI. The kernel will be slightly older .. but better and longer supported,
and it meets the 1.3 goals nicely.

linux-yocto-dev will pick up the slack for a newer kernel.

> 
> The more I think on it... the more I like the idea of a 3.4 LTSI only for
> 1.3. It would give us extra time to get the policy and config refactoring
> and the various tooling items done WELL and RIGHT. We would need to confirm
> with Greg that this aligns with his goals.

We completely agree. We just need to make sure that LTSI moves to meet us :)

Bruce

> 
> Thoughts?

This won't happen until 1.4 as LTSI-3.4 isn't likely to be released prior to November 2012.

Status -> WaitForUpstream

We want to do this as soon as possible, but we are dependent on LTSI 3.4. We should have this done by M3 at the latest to allow for a full milestone of testing the LTSI kernels. Marking as M3.

Patches have been merged, staged and build tested. 

http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?id=28a6f08b98bf888a3dd5ed8bd00d41f925bf9ee0

boot testing remains before the tree will be pushed for general use.

commit 09d0bc521ad34473acf2ec4a00a69c3e3183f7d9
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Fri Jan 18 00:19:31 2013 -0500

    linux-yocto/3.4: integrate LTSI-3.4
    
    Updating the linux-yocto-3.4 SRCREVS to activate the merge of the 3.4.25-ltsi
    tree:
    
       http://git.linuxfoundation.org/?p=ltsi-kernel.git;a=tag;h=refs/tags/v3.4.25-ltsi
    
    The pristine patch queue can be seen on the "ltsi" branch in the repository.
    This branch has been merged into the standard/base branch of linux-yocto-3.4
    and to all BSP branches in the tree.
    
    LTSI based BSPs or features are not activated as part of this commit, they
    are controlled by the meta branch of the kernel repository and are activated
    in separate patches.
    
    [YOCTO #2396]
    
    (From OE-Core rev: 8f03ebe9b164e0c0493c56d9eb2e7d0b039832f1)
    
    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

LTSI is now merged into the 3.4 tree. It can be seen as the discrete "ltsi" branch, which
is also merged into each and every BSP. There's no explicit action required to "use LTSI", 
you simply get it in each build. The features can be enabled via fragments as required, or
left latent.

Test case added:  https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=742

Build Configuration:
BB_VERSION        = "1.17.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Gentoo-n-a"
TARGET_SYS        = "i586-poky-linux"
MACHINE           = "atom-pc"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130326"
TUNE_FEATURES     = "m32 core2"
TARGET_FPU        = ""
meta              
meta-yocto        
meta-yocto-bsp    = "master:f36926a264190e6202830e8520b41b30ae77ea43"