Rev 1: Start with Andrew Bennetts presentation, at least it has the basics. in http://bzr.arbash-meinel.com/branches/bzr/presentations/presentation-2007-07-01

John Arbash Meinel john at arbash-meinel.com
Sun Jul 1 03:16:58 BST 2007


At http://bzr.arbash-meinel.com/branches/bzr/presentations/presentation-2007-07-01

------------------------------------------------------------
revno: 1
revision-id: john at arbash-meinel.com-20070701021657-d64c3oxwuyytd0ni
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: presentation-2007-07-01
timestamp: Sat 2007-06-30 21:16:57 -0500
message:
  Start with Andrew Bennetts presentation, at least it has the basics.
added:
  .bzrignore                     bzrignore-20070701021634-dtpuoscknj3wtliu-1
  bzr-viz.png                    bzrviz.png-20070701021619-s5arvddrnf3pkh0u-1
  canonical-horiz2.png           canonicalhoriz2.png-20070701021619-s5arvddrnf3pkh0u-2
  slides.tex                     slides.tex-20070701021441-o286fkqxodyvxqqq-1
-------------- next part --------------
=== added file '.bzrignore'
--- a/.bzrignore	1970-01-01 00:00:00 +0000
+++ b/.bzrignore	2007-07-01 02:16:57 +0000
@@ -0,0 +1,7 @@
+*.aux
+*.log
+*.nav
+*.out
+*.pdf
+*.snm
+*.toc

=== added file 'bzr-viz.png'
Binary files a/bzr-viz.png	1970-01-01 00:00:00 +0000 and b/bzr-viz.png	2007-07-01 02:16:57 +0000 differ
=== added file 'canonical-horiz2.png'
Binary files a/canonical-horiz2.png	1970-01-01 00:00:00 +0000 and b/canonical-horiz2.png	2007-07-01 02:16:57 +0000 differ
=== added file 'slides.tex'
--- a/slides.tex	1970-01-01 00:00:00 +0000
+++ b/slides.tex	2007-07-01 02:16:57 +0000
@@ -0,0 +1,303 @@
+\documentclass[utf8x]{beamer}
+
+\usepackage{beamerthemesplit}
+
+\title{Coding in a Distributed Team}
+\subtitle{Testing, Reviewing, Sharing and Merging Code Without Going Crazy}
+\author{Andrew Bennetts \\ \texttt{andrew at puzzling.org}}
+
+\date{8th December, 2006}
+
+\logo{\pgfimage{canonical-horiz2}}%
+\setbeamertemplate{navigation symbols}{}   % hide the navigation symbols
+
+\begin{document}
+
+\frame{\titlepage}
+
+\section{Introduction}
+\subsection*{Outline}
+\begin{frame}%[allowframebreaks]
+\small{
+\tableofcontents
+}
+\end{frame}
+
+\subsection{Who am I?}
+\begin{frame}{\insertsubsection}
+
+    I work on \ldots
+
+    \begin{itemize}
+        \item{Launchpad --- \url{https://launchpad.net/}}
+        \item{Bazaar --- \url{http://bazaar-vcs.org/}}
+        \item{Twisted --- \url{http://twistedmatrix.com/}}
+    \end{itemize}
+\end{frame}
+
+\subsection{Some common problems}
+\begin{frame}{\insertsubsection}
+% making sure that developers on one side of the world aren't blocked for
+% a day on colleagues on the other side of the world}
+``I need an answer from Steve\ldots \pause but Steve is in Lithuania.''
+\end{frame}
+            
+%\begin{frame}{\insertsubsection}
+%% coping with parellel development 
+%``I need a bugfix from Steve\ldots \pause but it hasn't landed on trunk yet.''
+%\end{frame}
+            
+\begin{frame}{\insertsubsection}
+% allowing all developers to work on a functional shared codebase}
+%
+% and checking that code works before checking it into the shared codebase
+``That \#?\%\$ing Australian checked in broken code\ldots \pause \emph{again}!''
+\end{frame}
+
+\section{The Trunk}
+\begin{frame}\begin{center}\Huge\insertsection\end{center}\end{frame}
+\subsection{Tests must always pass on the trunk}
+\begin{frame}{\insertsubsection}
+    Tests must always pass on the trunk. \\ \pause
+    Tests must always pass on the trunk. \\ \pause
+    \textbf{Tests must always pass on the trunk.}
+\end{frame}
+
+\begin{frame}{\insertsubsection}
+    \ldots you do have an automated test suite, right?
+\end{frame}
+
+\begin{frame}{\insertsubsection}
+    If tests don't pass, developers are impeded.  They can't safely commit
+    changes to the trunk.  They can't safely start new work. \\
+    \pause
+    ~\\
+    It's just bad.
+\end{frame}
+
+\subsection{Enforcing that tests pass}
+\begin{frame}{\insertsubsection}
+    Make sure tests pass on the trunk \pause --- automate it.
+\end{frame}
+
+\begin{frame}{\insertsubsection ~with PQM}
+    PQM (Patch Queue Manager) is a tool to enforce that tests pass. \\
+    ~\\
+    Only PQM can commit to trunk.  Developers do not have write access to trunk.
+    PQM is configured to run the test suite before accepting a change.  It
+    accepts merge requests (as GPG-signed emails) and checks that they are good
+    before committing them. \\
+    ~\\
+    Launchpad and Bazaar use PQM.
+    ~\\
+    \url{http://bazaar-vcs.org/PatchQueueManager}
+\end{frame}
+
+\begin{frame}{\insertsubsection ~with Buildbot}
+    Buildbot is a less intrusive (but less strict) way to enforce passing tests. \\
+    ~\\
+    Buildbot watches the trunk, and when a commit happens, it kicks off one or
+    more ``builds'', and reports the results. \\
+    ~\\
+    \emph{$<$buildbot$>$ Hey! andrew broke the build!}\\
+    ~\\
+    Twisted uses Buildbot. \\
+    ~\\
+    \url{http://buildbot.sourceforge.net/}
+\end{frame}
+
+\subsection{Coping with inter-dependent projects}
+
+\begin{frame}{\insertsubsection}
+    Launchpad depends on many other projects:
+    \begin{itemize}
+        \item Twisted
+        \item SQLObject
+        \item Zope 3
+        \item and so on\ldots
+    \end{itemize}
+\end{frame}
+
+\begin{frame}{\insertsubsection}
+    In many cases, we need development versions, or heavily patched versions. \\
+    ~\\
+    \pause
+    Each time we patch or upgrade, there's a risk of breaking Launchpad trunk.
+    \\
+    \pause
+    ~\\
+    Which means tests don't pass, which means PQM rejects \emph{all} our
+    commits.  Oops.
+\end{frame}
+
+\begin{frame}{\insertsubsection}
+    So, we manage these dependencies with PQM too. \\
+    ~\\
+    For example, if we update our Twisted, PQM runs the Twisted test suite
+    \emph{and} the Launchpad test suite before accepting the commit.
+\end{frame}
+
+\section{Mandatory Code Reviews}
+\begin{frame}\begin{center}\Huge\insertsection\end{center}\end{frame}
+\subsection{Reviews improve code quality}
+\begin{frame}{\insertsubsection}
+    The usual reasons for code reviews all apply in a distributed team.  They
+    can catch:
+    \begin{itemize}
+        \item bugs
+        \item coding style inconsistencies
+        \item unreadable code
+        \item insufficiently tested code
+    \end{itemize}
+\end{frame}
+\subsection{Reviews spread knowledge}
+\begin{frame}{\insertsubsection}
+    Distributed teams don't:
+    \begin{itemize}
+        \item gather around watercoolers
+        \item eat lunch together
+        \item overhear conversations in the next cubicule
+    \end{itemize}
+\end{frame}
+
+\begin{frame}{\insertsubsection}
+    Code reviews help spread knowledge around the team that might not otherwise
+    spread.
+
+    \begin{itemize}
+        \item infrastructure that can be reused: ``You can use FooHelper here
+            instead of writing that yourself.''
+        \item infrastructure that is needed: ``That's the third time someone has
+            had write that.''
+        
+    \end{itemize}
+
+    People working on a common project tend to bump into common problems and
+    solutions.
+\end{frame}
+
+
+\subsection{How to manage reviews}
+\begin{frame}{\insertsubsection}
+    All developers should be able read and comment on reviews, whether on a
+    mailing list or in a bug/ticket. \\
+    ~\\
+    \pause
+    Launchpad uses a wiki page and cron job to pre-generate diffs for reviewers.
+    Robert assigns reviews to reviews daily.  Reviews are sent to a mailing
+    list.\\
+    ~\\
+    \pause
+    Bazaar uses its mailing list, and website called ``BundleBuggy'' helps track
+    the review requests and responses. \\
+    ~\\
+    \pause
+    Twisted uses its Trac ticket tracker.  Every branch has a ticket, tickets
+    with the ``review'' keyword are automatically in the review queue. 
+\end{frame}
+
+\section{Bazaar: Distributed Version Control}
+\begin{frame}\begin{center}\Huge%
+Bazaar:\\%
+Distributed Version Control%
+\end{center}\end{frame}
+\subsection{What is distributed version control?}
+\begin{frame}{\insertsubsection}
+See previous talk!
+\end{frame}
+
+\subsection{Positive Effects}
+
+\begin{frame}{Branching and merging}
+    Distributed Version Control tools all have excellent branching and merging
+    support. \\
+    ~\\
+    This is great for distributed teams.  Each developer can have a branch for
+    each feature or bug they work on, and can merge back-and-forth with other
+    developers easily.
+\end{frame}
+\begin{frame}{Feature branches}
+    Good branching and merging support encourages \emph{feature branches}.\\
+    ~\\
+    \pause
+    Feature branches have a single, specific purpose: ``Add feature X'', or
+    ``Fix bug \#1234''.\\
+    ~\\
+    \pause
+    Simpler, single-purpose branches are easier to review.
+\end{frame}
+\begin{frame}{Smaller commits}
+    Because commits are usually on a branch, rather than on the trunk, you do
+    smaller commits.\\
+    ~\\
+    This helps tools like ``annotate''.
+\end{frame}
+
+\begin{frame}%
+\begin{centering}%
+  \pgfimage[width=0.9\paperwidth]{bzr-viz}%
+\end{centering}%
+\end{frame}
+
+\subsection{Why Bazaar?}
+\begin{frame}{\insertsubsection}
+\begin{itemize}
+	\item{it's written in Python}
+        \pause
+	\item{it's easy to use}
+        \pause
+	\item{the ``uncommit'' command}
+        \pause
+	\item{the ``shelve'' command (part of the
+		bzrtools plugin $<$\url{http://bazaar-vcs.org/BzrTools}$>$)}
+        \pause
+	\item{PQM already works with it.}
+\end{itemize}
+\end{frame}
+
+\section{The End}
+\begin{frame}\begin{center}\Huge%
+The End\\%
+(almost)%
+\end{center}\end{frame}
+\subsection{Stuff I didn't talk about}
+\begin{frame}{\insertsubsection}
+Stuff I haven't mentioned --- but probably should have:
+\begin{itemize}
+    \item{\textbf{VOIP:} talking is better than email and IRC for some things.}
+    \item{\textbf{distributed pair programming:} I hear screen \& VOIP work well.}
+%    \item{XXX}
+%    \item{\ldots}
+\end{itemize}
+\end{frame}
+
+\subsection{Summary}
+\begin{frame}{\insertsubsection}
+\begin{itemize}
+	\item{Require --- and enforce --- that the trunk \emph{always} builds and
+        passes tests.}
+	\item{Require code reviews to commit to the trunk.}
+	\item{Use a distributed revision control tool.}
+\end{itemize}
+    
+\end{frame}
+
+\subsection{Questions?}
+\begin{frame}{\insertsubsection}%
+    \begin{center}\Huge{Questions?}\end{center}
+\end{frame}
+
+
+
+
+%\frame
+%{
+%  \frametitle{Features of the Beamer Class}
+%
+%  \begin{itemize}
+%  \item<1-> Normal LaTeX class.
+%  \item<2-> Easy overlays.
+%  \item<3-> No external programs needed.      
+%  \end{itemize}
+%}
+\end{document}



More information about the bazaar-commits mailing list