\documentclass[aspectratio=169,obeyspaces,spaces,hyphens]{beamer}
\usepackage[utf8]{inputenc}
\usepackage{minted}
\usepackage{amssymb}

\mode<presentation>
\usetheme{Bootlin}

\newcommand{\codehack}[1]{{\usebeamercolor[fg]{code} {\tt #1}}}

\title{Kernel maintainership: an oral tradition}
\authors{Gregory CLEMENT}
\institute{Bootlin}

\usepackage{hyperref}

\begin{document}

\begin{frame}{Embedded Linux Conference Europe 2015}
  \begin{columns}[c]
    \column{0.45\textwidth}
    \huge
    Kernel maintainership: an oral tradition\\
    \column{0.55\textwidth}
    \begin{center}
    \includegraphics[width=\textwidth]{penguins_group.jpg}

    \tiny
    (Image credit: Andrew Cheal under license CC BY-ND 2.0)
    \end{center}
  \end{columns}
  \Large
  Gregory CLEMENT\\
  {{\itshape{\bfseries Bootlin}}}\\
  \normalsize
  {\em gregory.clement@bootlin.com}
  \vfill
\end{frame}

\begin{frame}{Gregory CLEMENT}
  \begin{columns}
    \column{0.7\textwidth}
    \begin{itemize}
    \item Embedded Linux engineer and trainer at {\bf Bootlin}
      \begin{itemize}
      \item Embedded Linux {\bf expertise}
      \item {\bf Development}, consulting and training
      \item Strong open-source focus
      \end{itemize}
    \item Open-source contributor
      \begin{itemize}
      \item Contributing to {\bf kernel support for the Armada 370,
          375, 38x, 39x and Armada XP} ARM SoCs from Marvell.
      \item Co-maintainer of mvebu sub-architecture (SoCs from Marvell
        Engineering Business Unit)
      \item Living near {\bf Lyon}, France
      \end{itemize}
    \end{itemize}
    \column{0.3\textwidth}
    \includegraphics[width=\textwidth]{common/logo-square.pdf}\\
  \end{columns}
\end{frame}

\begin{frame}{Motivation and Overview}
  \begin{itemize}
  \item Motivation
    \begin{itemize}
    \item Implicit or unwritten rules.
    \item Make such rules more explicit.
    \item Help new maintainers and contributors.
    \item Guidelines I would have liked to find.
    \end{itemize}
  \item Overview
    \begin{itemize}
    \item The role of a maintainer
    \item Accepting a patch
    \item Interaction with other maintainers
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{The role of a maintainer}
  \begin{itemize}
  \item Gathering patches for the subsystem
    \begin{itemize}
    \item Through emails.
    \item Sometimes through a git tree.
    \end{itemize}
  \item Reviewing the submitted patches
    \begin{itemize}
    \item Best case: accepted as is.
    \item Most often: ask for a new version pointing the parts to improve.
    \item Worst case: rejected.
    \end{itemize}
  \item Pushing the gathered patches to the upper subsystem
    \begin{itemize}
    \item Pull request to another maintainer.
    \item Or directly to Linus Torvalds.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Becoming a maintainer}
  \begin{itemize}
  \item Creating a new subsystem:
    \begin{itemize}
    \item Most obvious.
    \item Under \code{arch/} usually a new family of a \textbf{CPU} or
      an {\bf SoC}.
    \item Under \code{drivers/} usually a new {\bf framework} or a
      \textbf{specialization} of an existing class driver.
    \end{itemize}
  \item Joining the current maintainer:
    \begin{itemize}
    \item After being active in the subsystem especially by doing
      reviews.
    \item Generally asked by the current maintainer(s) but sometimes
      after offering help.
    \end{itemize}
  \item Replacing a maintainer:
    \begin{itemize}
    \item Either co-opted by the current maintainer before leaving.
    \item Or asked by upper maintainer because of your involvement in
      this subsystem.
    \item Or on a volunteering base because you are interested by the
      subject (and because you need to push your own patches).
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Expectation of the submitter}
  \begin{columns}
    \column{0.7\textwidth}
  \begin{itemize}
  \item Reviewing the patch in a couple of days (or hours)
    \begin{itemize}
    \item Writing and testing the code took a long time, reviewing it
      should be fast.
    \item Eager to have feedback to make things move on.
%but even hobbyist or side task
% 1 week is very good, and 2 week is good
    \end{itemize}
  \item Knowing the hardware by heart
    \begin{itemize}
    \item As maintainer of the subsystem you appear as the expert of
      the hardware it supports.
    \item Supposed to have all the variants of the hardware.
    \end{itemize}
  \item Updating the status of the submitted patches
    \begin{itemize}
    \item Letting know if the patches have been received, reviewed,
      applied or rejected.
    \item Expected to be done in real time.
    \end{itemize}
  \end{itemize}
   \column{0.3\textwidth}
    \begin{center}
      \includegraphics[width=\textwidth]{parent_penguin.jpg}
      \end{center}
  \end{columns}
\end{frame}

\begin{frame}{Expectation of the upper maintainer}
  \begin{columns}
    \column{0.5\textwidth}
    \begin{itemize}
    \item Don't introduce any breakage.
    \item No merge conflict.
    \item No regression.
    \end{itemize}
    \column{0.5\textwidth}
    \begin{center}
      \includegraphics[width=0.5\textwidth]{stuffed_penguin.jpg}

      \tiny
      (Image credit: Mike Pennington under license CC BY-SA 2.0)
      \end{center}
  \end{columns}
\end{frame}

\begin{frame}{Timeline for the submission of a patch 1/3}
  \begin{itemize}
  \item At least one week between submission and being applied
    \begin{itemize}
    \item Leave time to interested people to review the series
    \item Could be shorter for a new version of a series already reviewed
    \end{itemize}
  \item Stay in linux-next one week before being submitted to the
    upper subsystem
    \begin{itemize}
    \item Allows to fix merge conflicts before creating an immutable
      branch.
    \item Could be shorter if already been in linux-next before or if
      the changes are well contained.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Timeline for the submission of a patch 2/3}
  \begin{itemize}
  \item The deeper the subsystem is, the longer will be the time between
    submission and being merged in mainline
  \end{itemize}
  \includegraphics[width=\textwidth]{submission-process.eps}
\end{frame}

\begin{frame}{Timeline for the submission of a patch 3/3}
  \begin{itemize}
  \item As the Linux release candidates are weekly, then for a
    subsystem at N-1, series submitted after -rc6 (or rc7) won't be in
    the next release.
  \end{itemize}
  \includegraphics[width=\textwidth]{timeline-submission.eps}
\end{frame}

\begin{frame}{Accepting a patch}
  \begin{itemize}
  \item Obvious criteria
    \begin{itemize}
    \item Must respect the coding rules (use \code{checkpatch.pl}  for this).
    \item Must compile without warning.
    \end{itemize}
  \item No regression.
  \item Testing the hardware is nice to have but not mandatory.
    \begin{itemize}
    \item For a new device feature or device you can assume it was
      tested by the submitter.
    \item Ask for a \code{Tested-by} from other users if you have any doubt.
    \item Rely on testing farms if you can.
    \end{itemize}
  \item Be careful of dependencies with other subsystems.
  \end{itemize}
\end{frame}

\begin{frame}{Organization of the subsystem git tree}
  \begin{itemize}
  \item At least 2 branches:
    \begin{itemize}
    \item \code{current} for gathering the fixes of the current
      release candidate.
    \item \code{for-next} for gathering the patches for the next
      release candidate.
    \end{itemize}
  \item Could be useful to have a third branch for the release
    candidate after.
  \item Could have topic branches:
    \begin{itemize}
    \item For big subsystems such as \code{arm-soc}.
    \item To let other subsystems merge your subsystem related part
      of series (see later).
    \end{itemize}
  \item Based on the -rc1 to make the merge easier.
  \end{itemize}
\end{frame}

\begin{frame}{The stable kernels}
  \begin{itemize}
  \item Most users use a kernel from a distribution.
  \item Most distributions use stable kernels.
  \item When receiving a fix, always ask if it could be useful for
    older kernels.
  \item Tag the commit with \code{Cc: <stable@vger.kernel.org>}.
  \item Indicate from which from which version it applies by adding it in comment.
  \item Even better use the tag \code{ Fixes: SHA-1_ID ("title of the patch")}.
  \end{itemize}
\end{frame}

\begin{frame}{The linux-next kernel 1/2}
  \begin{itemize}
  \item The place where are merged all the commits expected to be in
    the kernel after the next merge window closes.
  \item How to use it as a maintainer
    \begin{itemize}
    \item The branches merged in linux-next have to be declared to
      Stephen Rothwell.
    \item Send him an email with the name of the repository and the
      branch to merge.
    \item Do not have to be an immutable branch: all the branches are
      merged again for each linux-next release (on a daily basis).
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{The linux-next kernel 2/2}
  \begin{itemize}
  \item Benefit of being in \code{linux-next}
    \begin{itemize}
    \item Being merged every day with all the other branches allows
      to detect the merge conflicts early.
    \item As a bonus, Stephen often resolves the conflict.
    \item Used by the autobuilder such as \code{0-Day} done by
      \code{01.org} from \code{Intel} or the \code{kernel CI} supported
      by \code{Linaro}.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Automatic tester projects}
  \begin{itemize}
  \item Projects which automatically test your branch
  \item \code{0-Day}:
    \begin{itemize}
    \item Fetches the branches from the main kernel repository (at least \code{git.kernel.org}).
    \item Compiles test various defconfig and architecture.
    \item Boots and does some performance tests on hardware.
    \item Now seems also to apply patches directly from the mailing lists.
    \end{itemize}
  \item \code{kernel CI}:
    \begin{itemize}
    \item Compiles several branches mainly ARM related.
    \item Boots and test on many boards.
    \item Fancy website to retrieve the results.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Dealing with your own patches}
  \begin{itemize}
  \item You are a maintainer but you remain a developer.
  \item You have the possibility to directly apply your own patches.
  \item Not really in the spirit of an open development.
  \item Still good to have reviews and suggestions.
  \item However most of the time you won't get a review as you are
    supposed to be the one who reviews!
  \item But still apply the submission process: waiting at least one
    week after submitting to the mailing list before applying the patch
    in your \code{-next} branch.
  \end{itemize}
\end{frame}

\begin{frame}{Coordinating with the co-maintainers 1/2}
  \begin{itemize}
  \item Subsystems maintained more and more often by several people.
  \item Benefits:
    \begin{itemize}
    \item Allows to be more responsive especially if located in distant
      timezones.
    \item Avoids having a stalled subsystem during holidays.
    \item Eases the turn over: easier to leave and easier to join a
      team.
    \end{itemize}
  \item Drawbacks
    \begin{itemize}
    \item Need to find an agreement in case of opposite opinions.
    \item Need to coordinate.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Coordinating with the co-maintainers 2/2}
  \begin{itemize}
  \item Each co-maintainer has her/his own interests and fields of
    expertise.
    \begin{itemize}
    \item Spreads the review.
    \item Allows to stay focused.
    \end{itemize}
  \item An \code{Acked-by} given by a co-maintainer is enough.
  \item Only one co-maintainer gathering the patches and taking care
    of the pull requests for a given kernel release cycle.
    \begin{itemize}
    \item Easier to keep track of the submitted patches.
    \item The git repository remains shared at least for emergency.
    \item Better to decide in advance who will be the next in charge.
    \end{itemize}
  \item Coordinating by email is fine most of the time.
  \end{itemize}
\end{frame}

\begin{frame}{Coordinating with the maintainers of other subsystems 1/2}
  \begin{itemize}
  \item Some series modify several subsystems at the same time.
  \item Dependencies between the patches.
  \item We want the kernel to be \emph{bisectable}.
  \item The order in which the patches are applied matters.
  \item Can't predict in which order the subsystem will be merged.
  \item Need to synchronize with the maintainers of other subsystems
    to solve this.
  \end{itemize}
\end{frame}

\begin{frame}{Coordinating with the maintainers of other subsystems 2/2}
  \begin{itemize}
  \item One maintainer takes the entire series:
    \begin{itemize}
    \item Will have commits modifying another subsystem in her/his
      git tree.
    \item May cause merge conflicts.
    \end{itemize}
  \item One maintainer creates an immutable branch
    \begin{itemize}
    \item A topic branch with only the patch from the series.
    \item Will be in both trees: it will avoid the merge conflict.
    \item If a fix is needed, it can't be squashed, it will have to be a
      separate commit.
    \end{itemize}
  \item Merging the series in two kernel releases:
    \begin{itemize}
    \item No merge conflict.
    \item No immutable branch.
    \item But the feature is delayed of at least 3 months.
    \item Still possible to have the feature by delaying the clean-up
      in the second release.
    \end{itemize}
  \end{itemize}
\end{frame}

\newcommand{\tabitem}{{\color{blblue} $\blacktriangleright$}}

\begin{frame}{Submitting the gathered patches 1/2}
  \begin{tabular}{p{0.35\textwidth} p{0.65\textwidth}}
    \tabitem Identify the patches to apply when reading the emails. & \code{M-x gnus-registry-set-article-mark} under
    \code{emacs} or by using \code{patchwork}. \\
    \tabitem Apply them on your branch. & \code{M-x dvc-gnus-article-apply-patch} under
      \code{emacs}. \\
    \tabitem Add your \code{Signed-off-by} (as you are going to submit them you
    have to do it). & \code{git commit --amend -s --no-edit}\\
  \end{tabular}
\end{frame}

\begin{frame}{Submitting the gathered patches 2/2}
  \begin{tabular}{p{0.35\textwidth} p{0.65\textwidth}}
   \tabitem   Sign your branch & \code{git tag -s tag_name branch_name} \\
    \tabitem   Push your branch on your public repository & \code{git push public_repo tags/tag_name}\\
    \tabitem   Generate the pull request cover letter: & \code{git request-pull previous_tag public_repo \ tags/tag_name | cat}

      \code{previous_tag} is either the tag previously pulled during the
      last request or the \code{rc1} of the current kernel. \\
  \end{tabular}
\end{frame}


\begin{frame}{Final words}
 \begin{columns}
    \column{0.5\textwidth}
  \begin{itemize}
  \item Find the good balance between maintainer duty and submitter
    expectations.
  \item Be nice and helpful with the submitters especially the new
    ones.
  \item Remain vigilant about the code quality and stability of the
    kernel.
  \end{itemize}
  \column{0.5\textwidth}
    \begin{center}
      \includegraphics[width=\textwidth]{family_penguin.jpg}
      \end{center}
  \end{columns}
\end{frame}


\begin{frame}
  \begin{center}
    \LARGE
    Questions?\\
    \vspace{2.5cm}
    \small
    Gregory CLEMENT\\
    \code{gregory.clement@bootlin.com}\\
    \vspace{0.5cm}
    Slides under CC-BY-SA 3.0\\
    \scriptsize
    \url{http://bootlin.com/pub/conferences/2015/elce/clement-kernel-maintainership-oral-tradition}
  \end{center}
\end{frame}

\end{document}
