Skip to main content


New LTSI Kernels are released every year, and the followings are the step by step process of LTSI Kernel Development.

Before the release, there are a few steps developers are required /encouraged to go through. The followings are the descriptions of each steps.

New LTSI Version Announcement
The Kernel version that will eventually become LTS/LTSI will be selected by Greg Kroah-Hartman and announced once a year, the timing of the announce varies every year depending upon the situation of the Kernel development. The announcement will be made through LTSI mailing list , LTSI website and LTSI Twitter (@LinuxLTSI).

At the announcement, LTSI Project will provide the formal development schedule of the year.

Thus, developers are encouraged to start preparing for submitting patches to LTSI or even make sure to upstream the patches that they wish to back-port eventually to LTSI Kernel.

Preparation Period
Typically, LTSI will take 4-6 months of “Preparation Period”.

In 4-6 months, there would be 2-3 more new mainline Kernel would be released. So the companies and developers will have a change to merge the code in the upstream Kernel, that would eventually back-ported to LTSI Kernel.

Merge Window Period
Then LTSI opens up the Merge Window for one or two months.

During this period, the developers are required to submit patches (new features, divers and fixes) to LTSI over the mailing list. Ideally all LTSI patches should come from later released kernel or at leased Linux-next tree to secure community review, however exceptions can be accepted if the patches are 1) beneficial to wide range of users, 2) projected to be upstreamed near future,

Validation Period
Finally, LTSI will take a month of validation period.

ALL developers who submitted patches are required to participate to this validation process, and fix their patches if there is anything happened.

Formal Release & Patchwork
LTSI-dev ML is now able to track through patchwork

Patchwork ( is an open source software that tracks patches posted in mailing lists for development use. This tool is also utilized in sub-system mailing lists such as LKML, and is available at the following link –

Contrary to mailing lists which consist of a mixture of messages that are purely logic and actual source codes (patches), patchwork extracts only messages containing codes (patches). Locating patches is made extremely easy with patchwork.
Development efficiency is greatly improved by describing the path to the patch being tracked by patchwork in the build script known as the Yocto recipe where even patches that are not merged in the mailing list repository can be specified when compiling kernels.
LTSI patchwork website can be accessed from the following link –
Fuego is a test framework specifically designed for embedded Linux testing. It supports automated testing of embedded targets from a host system, as it’s primary method of test execution.