The Linux kernel source code includes support for a number of different schedulers - software entities that decide which tasks to run next. One of these schedulers - named PREEMPT_RT - aims to minimise the time taken to respond to an interrupt (the "latency"), which can be critical for some applications. For some reason this scheduler is on the edges of acceptability for the Linux maintainers - PREEMPT_RT support is not part of the standard source tree, but a set of patches to take the standard branches and add RT capability is hosted on kernel.org.
The Raspberry Pi Linux kernel branches consist of sets of patches on top of the upstream branches, much like the RT patch sets. Unfortunately the two sets of patches each expect to be applied to an unmodified kernel, which can cause conflicts when they are both applied. Resolving these conflicts can be tricky, requiring a fairly in-depth knowledge of the kernel software and a fair amount of perseverance - it's not a task that most users would manage.
I was approached by Tiejun Chen - a professional developer but acting in a personal capacity - about the possibility of collaborating on an official Raspberry Pi RT branch. He provided a few ideas of how it could work, incorporated my feedback, and the first result is now published as rpi-4.14.y-rt.
[ Gory detail alert - look away if you are squeamish:
The "-rt" branch has been assembled in such a way that mainline Linux commits and downstream RPi patches all appear without modification (using Git "merge" commits), and the RT patches are modified ("rebased") to apply on top of them. We aim to only add new commits on top of the existing ones - we won't rewrite history, there is no going back - so only the differences between patch sets will appear with each release. ]
The "-rt" branches will by necessity lag behind the non-rt branches, and this whole exercise is an experiment. In particular, we have no plans to switch our kernel builds to use PREEMPT_RT or to ship them as alternative kernels.
Articles about the PREEMPT_RT kernel tend to be very technical, but this Arch Linux page is more readable than most.
You can discuss this announcement here.