Added a slideset for lifecycle management to the management chapter.

This covers chosing the correct versions, grading the quality of
Open-Source componentes and showing the difference between Yocto
and Debian. It also covers the security aspects of lifecycle
management.

Signed-off-by: Jan Altenberg <jan.altenberg@linutronix.de

11 files changed, 345 insertions, 0 deletions

diff --git a/images/debian-cve.jpg b/images/debian-cve.jpg
new file mode 100644
index 0000000..e07db4f
--- /dev/null
+++ b/images/debian-cve.jpg
diff --git a/images/dev_cycle_kernel.dia b/images/dev_cycle_kernel.dia
new file mode 100644
index 0000000..b9a7264
--- /dev/null
+++ b/images/dev_cycle_kernel.dia
diff --git a/images/dev_cycle_kernel.jpg b/images/dev_cycle_kernel.jpg
new file mode 100644
index 0000000..3e4fc5a
--- /dev/null
+++ b/images/dev_cycle_kernel.jpg
diff --git a/images/kernel_org.png b/images/kernel_org.png
new file mode 100644
index 0000000..01358f0
--- /dev/null
+++ b/images/kernel_org.png
diff --git a/images/linux_qa.png b/images/linux_qa.png
new file mode 100644
index 0000000..89a46d5
--- /dev/null
+++ b/images/linux_qa.png
diff --git a/images/longterm.png b/images/longterm.png
new file mode 100644
index 0000000..2e0581a
--- /dev/null
+++ b/images/longterm.png
diff --git a/images/nvd.jpg b/images/nvd.jpg
new file mode 100644
index 0000000..018c333
--- /dev/null
+++ b/images/nvd.jpg
diff --git a/images/yocto-cve.jpg b/images/yocto-cve.jpg
new file mode 100644
index 0000000..48eaa78
--- /dev/null
+++ b/images/yocto-cve.jpg
diff --git a/management/Kconfig b/management/Kconfig
index c571129..0937529 100644
--- a/management/Kconfig
+++ b/management/Kconfig
@@ -15,5 +15,13 @@ config LICENSE_COMPLIANCE
 	help
 	 Introduction to Copyright, License Compliance and related
 	 tools and processes
+
+config LIFECYCLE_MANAGEMENT
+	bool "Lifecycle Management for Open-Source components"
+	default y
+	help
+	  How to select the correct versions, the correct build system and
+	  the correct distribution. How to handle these components over
+	  their product lifecycle.
 endif
 
diff --git a/management/lifecycle/Makefile b/management/lifecycle/Makefile
new file mode 100644
index 0000000..3755124
--- /dev/null
+++ b/management/lifecycle/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_LIFECYCLE_MANAGEMENT) += pres_lifecycle_en.pdf
diff --git a/management/lifecycle/pres_lifecycle_en.tex b/management/lifecycle/pres_lifecycle_en.tex
new file mode 100644
index 0000000..4416f0c
--- /dev/null
+++ b/management/lifecycle/pres_lifecycle_en.tex
@@ -0,0 +1,336 @@
+\input{configpres}
+
+\title{\lq Maintainance and Lifecycle Management\rq}
+\maketitle
+
+\subsection{QA / Selecting the correct versions}
+
+\begin{frame}
+\frametitle{Versioning of the Linux Kernel}
+\begin{itemize}
+\item 2.6.37
+\item 2.6.38
+\item 2.6.39
+\item 3.0
+\item ...
+\item 3.19
+\item 4.0
+\item ...
+\item 4.19
+\item 5.0
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{The release cycle of the Linux Kernel}
+\begin{figure}[h]
+\centering
+\includegraphics[width=8cm]{images/dev_cycle_kernel.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Stable releases of the Linux Kernel}
+\begin{itemize}
+\item Important bugfixes are being backported to older kernel versions
+\item It's always recommended to use the latest stable release of your kernel version
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{QA in the Linux Kernel}
+\begin{figure}[h]
+\centering
+\includegraphics[width=8cm]{images/linux_qa.png}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Longterm kernels}
+\begin{figure}[h]
+\centering
+\includegraphics[width=8cm]{images/kernel_org.png}
+\end{figure}
+kernel.org
+\end{frame}
+
+\begin{frame}
+\frametitle{Longterm kernels}
+\begin{figure}[h]
+\centering
+\includegraphics[width=8cm]{images/longterm.png}
+\end{figure}
+https://www.kernel.org/category/releases.html
+\end{frame}
+
+\begin{frame}
+\frametitle{Choosing a kernel version}
+\begin{itemize}
+\item Take the latest longterm release
+\item When the release goes EOL update to the most recent longterm
+\item Updating to the next longterm is less effort and less error
+prone than backporting
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Grading the quality of Open-Source components}
+\begin{itemize}
+\item Is the project actively maintained?
+\item How big is the community?
+\item How diverge is the community?
+\item Does it fullfil my technical requirements
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Quality assurance}
+\begin{itemize}
+\item QA from the projects is mostly based on Code Review
+\item Be aware that you might need to test on your specific hardware
+\item Since the variety of the use cases is so big, the community can't
+cover testing for these cases
+\item So, there's always a risk, that a specifig feature won't work
+\item Calculate time for this risk in your projects!
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Other aspects of quality assurance}
+\begin{itemize}
+\item Is license compliance handled correctly?
+\item For third-party deliveries: Are all needed documents
+for license compliance delivered?
+\item Does the supplier provide the results of a license scan?
+\item Is the compliance process of the supplier certified in some way?
+(e.g. OpenCHAIN)
+\item You shoud run a license scan
+\end{itemize}
+\end{frame}
+
+\subsection{Building your Linux system}
+\begin{frame}
+\frametitle{Different approaches of building your Linux distribution}
+\begin{itemize}
+\item Roll your own (have fun with that one... ;-))
+\item Using a pre-existing free distribution
+\item Vendor based Linux
+\item Commercial Linux distribution
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Basic requirements for a build system}
+Creating your custom distribution:
+\begin{itemize}
+	\item Linux Kernel
+	\item GNU Tools
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Overview}
+BUT: There are many addtional requirements:
+\begin{itemize}
+	\item Systemboot concept
+	\item Update concept
+	\item Security concept
+	\item Application development
+	\item Continious integration
+	\item Release builds
+	\item Versioning
+	\item Lizence Management
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Most importantly: Security}
+\begin{itemize}
+	\item Monitoring security advisories
+	\item Check if your product needs an update
+	\item Generating updates
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{What is YOCTO?}
+\begin{itemize}
+	\item Ecosystem (not a single Open-Source project!)
+	\item Collection of Embedded Linux projects and tools
+	\item Framework for the industry to publish BSPs
+	\item NOT a Linux Distribution
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Just a few words on security}
+	...and why you SHOULD think about it!!
+\end{frame}
+
+\begin{frame}
+\frametitle{Reasons people tell why they don't care about security}
+\begin{itemize}
+\item ''My device is running in a secure network''
+\item ''There's no interest in attacking my device''
+\item ''My software doesn't have any bugs''
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Reasons why they SHOULD care!}
+\begin{itemize}
+\item ''my device is running in a secure network''
+\item answer: Just check the media for the successful attacks on ''secure'' networks which happened the past few weeks
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Reasons why they SHOULD care!}
+\begin{itemize}
+\item ''there's no interest in attacking my device''
+\item answer: If it has a network interface there is always a reason. At least your device can send SPAM.
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Reasons why they SHOULD care!}
+\begin{itemize}
+\item ''my software doesn't have any bugs''
+\item answer 1: Oh well....dream on...
+\item answer 2: If your software doesn't, some library you are using might have critical issues
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{And if you are still not convinced}
+\begin{itemize}
+\item In future you might even be forced to care by law
+\item If you don't follow ''state of the art'' security techniques, you might be responsible for the results caused by any attack
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile]
+	\frametitle{OK, so back to Yocto...}
+	\begin{verbatim}
+	Since the Yocto Project is intended to be flexible
+	and meet the needs of many applications,
+	we leave policy-making decisions around security
+	to our end users.
+	\end{verbatim}
+	Source: https://wiki.yoctoproject.org/wiki/Security
+	\pause
+	\begin{verbatim}
+	Debian takes security very seriously.
+	We handle all security problems brought to our attention [...]
+	Many advisories [...] are published the same day
+	a vulnerability is made public
+	\end{verbatim}
+	Source: https://www.debian.org/security/index.en.html
+\end{frame}
+
+\begin{frame}[fragile]
+	\frametitle{Security}
+	YOCTO does:
+	\begin{itemize}
+		\item Keep software versions up-to-date
+		\item Fix critical software issues
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+	\includegraphics[width=\textwidth]{images/nvd.jpg}
+\end{frame}
+
+\begin{frame}
+	\includegraphics[width=\textwidth]{images/debian-cve.jpg}
+\end{frame}
+
+\begin{frame}
+	\includegraphics[width=\textwidth]{images/yocto-cve.jpg}
+	\\
+	This implies: Security tracking must be done by the Yocto user!
+\end{frame}
+
+\begin{frame}
+	\frametitle{Debian: Using an existing distribution}
+\end{frame}
+
+\begin{frame}
+	\frametitle{What is Debian?}
+	\begin{itemize}
+		\item A Linux Distribution (existing for more than 20 years)
+		\item Available for many CPU architectures: x86, ARM, PowerPC, MIPS
+		\item Debian is based on pre-compiled binary packages
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Debian package management}
+	\begin{itemize}
+		\item Simple licence management
+		\item Can be used for updates
+		\item Easy to be extended
+		\item Simple generation of custom packages
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Advantages of debian}
+	\begin{itemize}
+		\item Longevity
+		\item Packages (thousands of software packages are available and supported!)
+		\item No cross compilation
+		\item Security and Bugfixes!
+		\item Buildsystems for customization available (e.g. ELBE http://elbe-rfs.org/)
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Debian based Buildsystems}
+	\begin{itemize}
+		\item ELBE: http://elbe-rfs.org
+		\item ISAR: https://github.com/ilbers/isar
+		\item meta-debian: Meta-layer for Poky to build Debian sources
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Conclusion}
+	\begin{itemize}
+		\item Yocto helped to standardize the distribution of Linux BSPS
+		\item Yocto is NOT an Embedded Linux Distribution
+		\item Yocto / Poky is usually combined with a manufacturer layer and additional components
+		\item Debian is a pre-built disribution which can be used on embedded devices
+		\item Debian is very powerful when it comes to bug and security tracking
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Lifecycle Management}
+\begin{itemize}
+\item Don't underestimate the efforts for security tracking
+\item Re-use community efforts as much as possible
+\item Only use well maintained components
+\item Only maintain custom changes if it's really possible
+\end{itemize}
+\end{frame}
+
+\subsection{Interesting projects}
+
+\begin{frame}
+\frametitle{Debian longterm stable}
+\begin{itemize}
+\item At least 5 years of maintenance
+\item Handled by a group of volunteers and companies
+\item https://wiki.debian.org/LTS
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Civil infrastructure platform}
+\begin{itemize}
+\item https://www.cip-project.org/
+\end{itemize}
+\end{frame}
+
+\input{tailpres}