[FE training-materials-updates] Add development process/contribution slides
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Tue Oct 1 15:30:52 CEST 2013
Repository : git://git.free-electrons.com/training-materials.git
On branch : kernel-ng
Link : http://git.free-electrons.com/training-materials/commit/?id=01dc8dedbc53d9844f9350091e77eae55fc857f9
>---------------------------------------------------------------
commit 01dc8dedbc53d9844f9350091e77eae55fc857f9
Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date: Tue Oct 1 15:30:22 2013 +0200
Add development process/contribution slides
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>---------------------------------------------------------------
01dc8dedbc53d9844f9350091e77eae55fc857f9
Makefile | 2 -
.../kernel-development-process.tex | 234 ++++++++++++++++++++
.../kernel-resources-advice.tex | 88 --------
.../kernel-resources-title.tex | 2 +-
4 files changed, 235 insertions(+), 91 deletions(-)
diff --git a/Makefile b/Makefile
index 38abda4..5280e27 100644
--- a/Makefile
+++ b/Makefile
@@ -21,7 +21,6 @@ KERNEL_SLIDES = \
setup-lab \
kernel-introduction-title \
sysdev-linux-intro-features \
- sysdev-linux-intro-versioning \
kernel-embedded-linux-usage-title \
kernel-linux-intro-sources \
kernel-source-code-download-lab \
@@ -63,7 +62,6 @@ KERNEL_SLIDES = \
kernel-power-management-lab \
kernel-development-process \
kernel-resources-title \
- kernel-resources-advice \
kernel-resources-references \
last-slides
diff --git a/slides/kernel-development-process/kernel-development-process.tex b/slides/kernel-development-process/kernel-development-process.tex
index c05d2b0..b4f496f 100644
--- a/slides/kernel-development-process/kernel-development-process.tex
+++ b/slides/kernel-development-process/kernel-development-process.tex
@@ -1 +1,235 @@
\subsection{The kernel development and contribution process}
+
+\begin{frame}
+ \frametitle{Until 2.6 (1)}
+ \begin{itemize}
+ \item One stable major branch every 2 or 3 years
+ \begin{itemize}
+ \item Identified by an even middle number
+ \item Examples: \code{1.0.x, 2.0.x, 2.2.x, 2.4.x}
+ \end{itemize}
+ \item One development branch to integrate new functionalities and
+ major changes
+ \begin{itemize}
+ \item Identified by an odd middle number
+ \item Examples: \code{2.1.x, 2.3.x, 2.5.x}
+ \item After some time, a development version becomes the new base
+ version for the stable branch
+ \end{itemize}
+ \item Minor releases once in while: \code{2.2.23, 2.5.12}, etc.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Until 2.6 (2)}
+ \begin{center}
+ \includegraphics[width=\textwidth]{slides/sysdev-linux-intro-versioning/old-development-process.pdf}
+ \end{center}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Changes since Linux 2.6}
+ \begin{itemize}
+ \item Since \code{2.6.0}, kernel developers have been able to
+ introduce lots of new features one by one on a steady pace,
+ without having to make major changes in existing subsystems.
+ \item So far, there was no need to create a new development branch
+ (such as \code{2.7}), which would massively break compatibility
+ with the stable branch.
+ \item Thanks to this, {\bf more features are released to users at a
+ faster pace}.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{3.x stable branch}
+ \begin{itemize}
+ \item From 2003 to 2011, the official kernel versions were named \code{2.6.x}.
+ \item Linux \code{3.0} was released in July 2011
+ \item This is only a change to the numbering scheme
+ \begin{itemize}
+ \item Official kernel versions are now named \code{3.x}
+ (\code{3.0, 3.1, 3.2}, etc.)
+ \item Stabilized versions are named \code{3.x.y}
+ (\code{3.0.2, 3.4.3}, etc.)
+ \item It effectively only removes a digit compared to the previous
+ numbering scheme
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{New development model}
+ Using merge and bug fixing windows
+ \begin{center}
+ \includegraphics[width=\textwidth]{slides/sysdev-linux-intro-versioning/new-development-process.pdf}
+ \end{center}
+\end{frame}
+
+\begin{frame}
+ \frametitle{New development model - Details}
+ \begin{itemize}
+ \item After the release of a \code{3.x} version (for example),
+ a two-weeks merge window opens, during which major additions are merged.
+ \item The merge window is closed by the release of test version
+ \code{3.(x+1)-rc1}
+ \item The bug fixing period opens, for 6 to 10 weeks.
+ \item At regular intervals during the bug fixing period,
+ \code{3.(x+1)-rcY} test versions are released.
+ \item When considered sufficiently stable, kernel \code{3.(x+1)}
+ is released, and the process starts again.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{More stability for the kernel source tree}
+ \begin{columns}
+ \column{0.7\textwidth}
+ \begin{itemize}
+ \item Issue: bug and security fixes only released for most recent
+ stable kernel versions.
+ \item Some people need to have a recent kernel, but with long term
+ support for security updates.
+ \item You could get long term support from a commercial embedded
+ Linux provider.
+ \item You could reuse sources for the kernel used in Ubuntu Long
+ Term Support releases (5 years of free security updates).
+ \item The \url{http://kernel.org} front page shows which
+ versions will be supported for some time (up to 2 or 3 years),
+ and which ones won't be supported any more ("EOL: End Of Life")
+ \end{itemize}
+ \column{0.3\textwidth}
+ \includegraphics[width=\textwidth]{slides/sysdev-linux-intro-versioning/longterm-versions.png}
+ \end{columns}
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{What's new in each Linux release?}
+ \begin{itemize}
+ \item The official list of changes for each Linux release is just a
+ huge list of individual patches!
+\Tiny
+ \begin{verbatim}
+commit aa6e52a35d388e730f4df0ec2ec48294590cc459
+Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+Date: Wed Jul 13 11:29:17 2011 +0200
+
+ at91: at91-ohci: support overcurrent notification
+
+ Several USB power switches (AIC1526 or MIC2026) have a digital output
+ that is used to notify that an overcurrent situation is taking
+ place. This digital outputs are typically connected to GPIO inputs of
+ the processor and can be used to be notified of those overcurrent
+ situations.
+
+ Therefore, we add a new overcurrent_pin[] array in the at91_usbh_data
+ structure so that boards can tell the AT91 OHCI driver which pins are
+ used for the overcurrent notification, and an overcurrent_supported
+ boolean to tell the driver whether overcurrent is supported or not.
+
+ The code has been largely borrowed from ohci-da8xx.c and
+ ohci-s3c2410.c.
+
+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
+\end{verbatim}
+\normalsize
+ \begin{itemize}
+ \item Very difficult to find out the key changes and to get the
+ global picture out of individual changes.
+ \end{itemize}
+ \item Fortunately, there are some useful resources available
+ \begin{itemize}
+ \item \url{http://wiki.kernelnewbies.org/LinuxChanges}
+ \item \url{http://lwn.net}
+ \item \url{http://linuxfr.org}, for French readers
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Solving Issues}
+ \begin{itemize}
+ \item If you face an issue, and it doesn't look specific to your
+ work but rather to the tools you are using, it is very likely that
+ someone else already faced it.
+ \item Search the Internet for similar error reports.
+ \item You have great chances of finding a solution or workaround, or
+ at least an explanation for your issue.
+ \item Otherwise, reporting the issue is up to you!
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Getting Help}
+ \begin{itemize}
+ \item If you have a support contract, ask your vendor.
+ \item Otherwise, don't hesitate to share your questions and issues
+ \begin{itemize}
+ \item Either contact the Linux mailing list for your architecture
+ (like linux-arm-kernel or linuxsh-dev...).
+ \item Or contact the mailing list for the subsystem you're dealing
+ with (linux-usb-devel, linux-mtd...). Don't ask the maintainer
+ directly!
+ \item Most mailing lists come with a FAQ page. Make sure you read
+ it before contacting the mailing list.
+ \item Useful IRC resources are available too
+ (for example on \url{http://kernelnewbies.org}).
+ \item Refrain from contacting the Linux Kernel mailing list,
+ unless you're an experienced developer and need advice.
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Reporting Linux Bugs}
+ \begin{itemize}
+ \item First make sure you're using the latest version
+ \item Make sure you investigate the issue as much as you can: see
+ \kerneldoc{BUG-HUNTING}
+ \item Check for previous bugs reports. Use web search engines,
+ accessing public mailing list archives.
+ \item If the subsystem you report a bug on has a mailing list, use
+ it. Otherwise, contact the official maintainer (see the
+ \code{MAINTAINERS} file). Always give as many useful details as
+ possible.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{How to Become a Kernel Developer?}
+ \begin{itemize}
+ \item Recommended resources
+ \begin{itemize}
+ \item See \kerneldoc{SubmittingPatches} for guidelines
+ and \url{http://kernelnewbies.org/UpstreamMerge} for very
+ helpful advice to have your changes merged upstream (by Rik van
+ Riel).
+ \item Watch the \emph{Write and Submit your first Linux kernel
+ Patch} talk by Greg. K.H:
+ \url{http://www.youtube.com/watch?v=LLBrBBImJt4}
+ \item How to Participate in the Linux Community (by Jonathan
+ Corbet) A Guide To The Kernel Development Process
+ \url{http://j.mp/tX2Ld6}
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+
+\begin{frame}
+ \frametitle{How to Submit Patches or Drivers}
+ \begin{itemize}
+ \item Use git to prepare make your changes
+ \item Don't merge patches addressing different issues
+ \item Make sure that your changes compile well, and if possible, run well.
+ \item Run Linux patch checks: \code{scripts/checkpatch.pl}
+ \item Send the patches to yourself first, as an inline
+ attachment. This is required to let people reply to parts of your
+ patches. Make sure your patches still applies. See
+ \kerneldoc{email-clients.txt} for help configuring e-mail
+ clients. Best to use \code{git send-email}, which never corrupts
+ patches.
+ \item Run \code{scripts/get_maintainer.pl} on your patches, to know
+ who you should send them to.
+ \end{itemize}
+\end{frame}
diff --git a/slides/kernel-resources-advice/kernel-resources-advice.tex b/slides/kernel-resources-advice/kernel-resources-advice.tex
deleted file mode 100644
index 5b3f3bc..0000000
--- a/slides/kernel-resources-advice/kernel-resources-advice.tex
+++ /dev/null
@@ -1,88 +0,0 @@
-\subsection{Advice}
-
-\begin{frame}
- \frametitle{Solving Issues}
- \begin{itemize}
- \item If you face an issue, and it doesn't look specific to your
- work but rather to the tools you are using, it is very likely that
- someone else already faced it.
- \item Search the Internet for similar error reports.
- \item You have great chances of finding a solution or workaround, or
- at least an explanation for your issue.
- \item Otherwise, reporting the issue is up to you!
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Getting Help}
- \begin{itemize}
- \item If you have a support contract, ask your vendor.
- \item Otherwise, don't hesitate to share your questions and issues
- \begin{itemize}
- \item Either contact the Linux mailing list for your architecture
- (like linux-arm-kernel or linuxsh-dev...).
- \item Or contact the mailing list for the subsystem you're dealing
- with (linux-usb-devel, linux-mtd...). Don't ask the maintainer
- directly!
- \item Most mailing lists come with a FAQ page. Make sure you read
- it before contacting the mailing list.
- \item Useful IRC resources are available too
- (for example on \url{http://kernelnewbies.org}).
- \item Refrain from contacting the Linux Kernel mailing list,
- unless you're an experienced developer and need advice.
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Reporting Linux Bugs}
- \begin{itemize}
- \item First make sure you're using the latest version
- \item Make sure you investigate the issue as much as you can: see
- \kerneldoc{BUG-HUNTING}
- \item Check for previous bugs reports. Use web search engines,
- accessing public mailing list archives.
- \item If the subsystem you report a bug on has a mailing list, use
- it. Otherwise, contact the official maintainer (see the
- \code{MAINTAINERS} file). Always give as many useful details as
- possible.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{How to Become a Kernel Developer?}
- \begin{itemize}
- \item Recommended resources
- \begin{itemize}
- \item See \kerneldoc{SubmittingPatches} for guidelines
- and \url{http://kernelnewbies.org/UpstreamMerge} for very
- helpful advice to have your changes merged upstream (by Rik van
- Riel).
- \item Watch the \emph{Write and Submit your first Linux kernel
- Patch} talk by Greg. K.H:
- \url{http://www.youtube.com/watch?v=LLBrBBImJt4}
- \item How to Participate in the Linux Community (by Jonathan
- Corbet) A Guide To The Kernel Development Process
- \url{http://j.mp/tX2Ld6}
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-
-\begin{frame}
- \frametitle{How to Submit Patches or Drivers}
- \begin{itemize}
- \item Use git to prepare make your changes
- \item Don't merge patches addressing different issues
- \item Make sure that your changes compile well, and if possible, run well.
- \item Run Linux patch checks: \code{scripts/checkpatch.pl}
- \item Send the patches to yourself first, as an inline
- attachment. This is required to let people reply to parts of your
- patches. Make sure your patches still applies. See
- \kerneldoc{email-clients.txt} for help configuring e-mail
- clients. Best to use \code{git send-email}, which never corrupts
- patches.
- \item Run \code{scripts/get_maintainer.pl} on your patches, to know
- who you should send them to.
- \end{itemize}
-\end{frame}
diff --git a/slides/kernel-resources-title/kernel-resources-title.tex b/slides/kernel-resources-title/kernel-resources-title.tex
index 209980e..0164d67 100644
--- a/slides/kernel-resources-title/kernel-resources-title.tex
+++ b/slides/kernel-resources-title/kernel-resources-title.tex
@@ -1 +1 @@
-\section{Kernel Advice and Resources}
+\section{Kernel Resources}
More information about the training-materials-updates
mailing list