\documentclass[10pt]{beamer}%{{{

\mode<presentation> {
  \usetheme{Warsaw}
  \setbeamercovered{transparent}
}

\usepackage[english]{babel}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}

\usepackage{times}
%\usepackage[T1]{fontenc}
\newcommand{\git}{GIT}


\title{Packaging with \git}

\author{Pierre Habouzit}

\institute{FOSDEM 2008 - Debian Room}

\date{23 Feb. 2008}

\AtBeginSubsection[] {
  \begin{frame}<beamer>{Why choosing \git}
    \tableofcontents[currentsection,currentsubsection]
  \end{frame}
}

\begin{document}

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
  \tableofcontents
\end{frame}
%}}}
\section{Why choosing \git}%{{{

\begin{frame}{Because SVN isn't good enough}
  I've packaged with SVN on svn.debian.org for a long time…
  \uncover<2->{\alert{well, it sucks}:}
  \begin{itemize}
    \item<3-> I wasn't able to work without network access;
    \item<4-> I couldn't work incrementally: you have to get other's patches;
    \item<5-> I couldn't "try and see" and maybe discard some work without
              reverting patches: SVN never forgets;
    \item<6-> I like having the full upstream source at hand, but svn explodes
              doing that for large sources (KDE …).
  \end{itemize}
\end{frame}

\begin{frame}{Because \git{} does what I need}
  With \git, as a DSCM, most of the issues are gone.
  \begin{itemize}
    \item<2-> Off-line work is possible, in fact you always work off-line;
    \item<3-> Incremental work is possible;
    \item<4-> \git{} allow you to completely erase a wrong idea if you didn't
              shared it yet;
    \item<5-> \git{} storage is extremely efficient: the marginal cost of
              commits decreases with the number of commits.
  \end{itemize}
\end{frame}

\begin{frame}{A bit more about \git{} storage}
  \git{} storage is very efficient and optimized. Some numbers:

  \vspace{1em}
  \uncover<2->{
    xorg-xserver.git, goes back to 2000, is \alert{20Mo} big. The last
    orig.tar.gz is 8Mo big, more than 84Mo unpacked.
  }

  \vspace{1em}
  \uncover<3->{
    dpkg.git, whole history since April 1996, generates a git pack of
    \alert{15Mo}. The last dpkg release is 17Mo big unpacked.
  }

  \vspace{1em}
  \uncover<4->{
    GNU libc version 2.7 weights 115Mo unpacked. The full glibc history
    (starts in the eighties) generates a \git{} pack of \alert{104Mo}.
  }

  \vspace{1em}
  \uncover<5->{
    Though, this won't probably true for packages with a lot of binary stuff
    in it, where delta compression is less likely to produce good results
    (games data packages come to mind).
  }
\end{frame}

\begin{frame}{A real maintainer toolbox}
  \git{} is special, because it was designed by a {\bf Maintainer}.  This has
  several implications:
  \begin{itemize}
    \item<2-> \git{} operations to look at the history are blazingly fast;
    \item<3-> \git{} operations to integrate patches are blazingly fast;
    \item<4-> \git{} supports advanced merging features;
    \item<5-> \git{} has advanced patch manipulation features.
  \end{itemize}

  \vspace{1ex}

  \uncover<6->{
    In other words, \git{} is a suitable replacement for both SVN and
    quilt\footnote{or your preferred patch system}.
  }
\end{frame}

%}}}
\section{Repository layout}%{{{
\begin{frame}{The repository layout: upstream}
  First of all, my repositories contain upstream sources.
  \begin{enumerate}
    \item<2-> if upstream uses a public SVN or \git{} repository, I track
              their SCM under the {\tt upstream/*} namespace.
    \item<3-> if upstream tarballs differ from the SCM, I also add a
              {\tt upstream/tarballs} branch that replicates the tarball
              directly.
    \item<4-> if upstream only releases tarballs, I only have an
              {\tt upstream} branch that is the successive import of tarballs.

    \item<5-> last and not least, {\tt pristine-tar} helps me saving the
              pristine upstream tarballs inside git.
  \end{enumerate}
\end{frame}

\begin{frame}{The repository layout: upstream}
  \vspace{1ex}
  {\bf Demo}: tokyocabinet packaging:
  \begin{itemize}
    \item Step 1: importing upstream;
    \item Step 2: backing up the orig.tar.gz.
  \end{itemize}
\end{frame}

\begin{frame}{The repository layout: patches}
  Second of all, instead of using quilt, I use a private git branch to hold my
  patch queue (usually called {\tt \$\{upstream\_branch\}+patches}). There are many
  reasons to that:
  \begin{itemize}
    \item<2-> I only use one tool: \git{};
    \item<3-> quilt doesn't know about diff3, unpractical for partially merged
              patches;
    \item<4-> I believe it to be nicer to browse or to cherry-pick for
              upstreams.
  \end{itemize}
  \vspace{1ex}
  \uncover<5->{
    {\bf Demo:} let's rebase our patch branch for tokyocabinet !
  }
\end{frame}

\begin{frame}{The repository layout: debian packaging}
  Finally, everything that is Debian specific is kept into a debian branch.
  \begin{itemize}
    \item<2-> One branch per suite: {\tt debian-etch}, {\tt debian-sid}, {\tt
              debian-exp};
    \item<3-> the corresponding upstreams are merged into this {\tt debian}
              branch;
    \item<4-> the {\tt upstream+patches} branch is serialized under
              {\tt debian/patches}.
  \end{itemize}
  \vspace{1ex}
  \uncover<5->{
    {\bf Demo:} let's release our tokyocabinet package !
  }
\end{frame}
%}}}
\section{How to turn mud into gold efficiently}%{{{
\begin{frame}{Hiding to the world you're a dirty pig}
  There is nothing more useless than a crappy SCM history. I don't know how
  {\it you} work, but I tend to do everything at the same time.

  \vspace{1em}
  \uncover<2->{
    Well, then just bind {\tt :wa} to {\tt :wa<cr>:!git commit -a} in your
    editor…
  }

  \vspace{1em}
  \uncover<3->{
    Then work like a pig, compulsively saving\^{}Wcommiting your stuff…
  }

  \vspace{1em}
  \uncover<4->{
    And when you're happy of the current sate, let's pretend that you're a good
    boy.
  }

  \vspace{1em}
  \uncover<5->{
    {\bf Demo}: the same in pictures.
  }
\end{frame}
\begin{frame}{Using \git{} for other's packages}
  \git{} is not only useful as a versioning tool, it also helps to work fast
  with NMUs and security uploads.
  \begin{enumerate}
    \item<2-> {\tt \$ git init \&\& git add .\@{} \&\& git commit -asm.}
    \item<3-> {\it hack, hack …} {\tt \$ git commit -asm'try this'}
    \item<4-> {\it hack, hack …} {\tt \$ git commit -asm'try that'}
    \item<5-> {\it rebuild… Ok it works, let's produce a clean patch:}\\
              {\tt \$ git rebase -i [...]}
  \end{enumerate}

  \vspace{1ex}
  \uncover<6->{
    Some packages don't rebuild twice in a row properly, because their
    {\tt clean} target is broken…
  }

  \uncover<7->{
    \alert{I laugh at those}:\\
    {\tt \$ git clean -d \&\& git reset --hard}
  }
\end{frame}
%}}}
\section{The END !}%{{{

\begin{frame}{The END !}
  If you're not too bored already, I'll gladly answer your questions now.

  \vspace{2em}

  And remember, git has a tremendous community.

  \begin{center}
  {\tt <mailto:git@vger.kernel.org>}
  \end{center}

  Also consult the documentation:
  {\tt /usr/share/doc/git-doc/index.html}\footnote{I assume you have git-doc
  installed, it will soon be part of base}.
\end{frame}
%}}}
\end{document}
% vim:tw=78 spell spelllang=en:
