First commit

gdb-bof-cauldron-2019.org

@@ -0,0 +1,100 @@
+#+OPTIONS: toc:nil date:nil
+#+CREATOR: Emacs 26.1 (Org mode 9.1.9)
+#+TITLE: GDB tests, CI & Buildbot BoF
+#+AUTHOR: Sergio Durigan Junior @@latex:\\@@ sergiodj@redhat.com
+#+LANGUAGE: en
+
+* License
+
+- License: *Creative Commons Attribution 4.0 International License (CC-BY-4.0)*
+
+- https://creativecommons.org/licenses/by/4.0/
+
+* How was it?
+
+- GDB Buildbot started in 2015 as a personal project.
+
+#+BEAMER: \pause
+
+- We just had *2* machines serving *4* Fedora =x86_64= workers at the
+  time.  And no /try builds/!
+
+#+BEAMER: \pause
+
+- Initially it stored the test results in a git repository.  This
+  proved too inefficient over time...
+
+* And now?
+
+- The master runs in a dedicated VM at *OSCI* (@@latex:\textbf{O}@@pen
+  @@latex:\textbf{S}@@ource @@latex:\textbf{C}@@ommunity
+  @@latex:\textbf{I}@@nfrastructure).
+
+#+BEAMER: \pause
+
+- Most of our builders support /try builds/!
+
+#+BEAMER: \pause
+
+- *14* workers (*11* machines):
+
+  #+BEAMER: \pause
+
+  - Sergio (Red Hat): *2* machines (Fedora =x86_64=)
+
+  - Alan Hayward (ARM): *2* machines (Ubuntu =ARM 32= and =64=)
+
+  - Rainer Orth (CeBiTec.Uni-Bielefeld.DE): *2* machines (Solaris
+ =amd64= and =sparcv9=)
+
+  - David Edelsohn: *3* machines (RHEL 7.1 =s390x=, AIX =POWER8= and
+    Debian Jessie =s390x=)
+
+  - Edjunior Machado: *1* machine (CentOS 7 =PPC64LE=)
+
+  - Mark Wielaard: *1* machine (Fedora =s390x=)
+
+#+BEAMER: \pause
+
+- Test results are stored directly on-disk, and “garbage-collected”
+  every week (tests older than 4 months are deleted).
+
+* How does it work?
+
+- 
+
+* Notifications
+
+- To /gdb-testers/: whenever we detect a possible regression in an
+  upstream commit.
+
+#+BEAMER: \pause
+
+- To the /author/: on /try builds/, or when his/her commit broke GDB.
+
+#+BEAMER: \pause
+
+- To /gdb-patches/: when a commit breaks GDB.
+
+#+BEAMER: \pause
+
+- Breakage notifications are usually reliable.  Regression
+  notifications are not (just look at /gdb-testers/).
+
+* Problems and challenges
+
+- Racy testcases.  Perhaps the most difficult/persistent problem?
+
+#+BEAMER: \pause
+
+- Lots of test messages are non-unique.  This makes it really hard to
+  compare test results and find regressions.
+
+#+BEAMER: \pause
+
+- Better way to store and retrieve test results (current way is
+  “enough” for what we need, but it can certainly be improved).
+
+#+BEAMER: \pause
+
+- 

gdb-bof-cauldron-2019.tex

@@ -0,0 +1,164 @@
+% Created 2019-09-12 Thu 13:03
+% Intended LaTeX compiler: pdflatex
+\documentclass[presentation]{beamer}
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage{graphicx}
+\usepackage{grffile}
+\usepackage{longtable}
+\usepackage{wrapfig}
+\usepackage{rotating}
+\usepackage[normalem]{ulem}
+\usepackage{amsmath}
+\usepackage{textcomp}
+\usepackage{amssymb}
+\usepackage{capt-of}
+\usepackage{hyperref}
+\usepackage{color}
+\usepackage{listings}
+\usetheme{default}
+\author{Sergio Durigan Junior \\ sergiodj@redhat.com}
+\date{}
+\title{GDB tests, CI \& Buildbot BoF}
+\hypersetup{
+ pdfauthor={Sergio Durigan Junior \\ sergiodj@redhat.com},
+ pdftitle={GDB tests, CI \& Buildbot BoF},
+ pdfkeywords={},
+ pdfsubject={},
+ pdfcreator={Emacs 26.1 (Org mode 9.1.9)}, 
+ pdflang={English}}
+\begin{document}
+
+\maketitle
+
+\begin{frame}[label={sec:orgbad1c50}]{License}
+\begin{itemize}
+\item License: \alert{Creative Commons Attribution 4.0 International License (CC-BY-4.0)}
+
+\item \url{https://creativecommons.org/licenses/by/4.0/}
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile,label={sec:org4538604}]{How was it?}
+ \begin{itemize}
+\item GDB Buildbot started in 2015 as a personal project.
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item We just had \alert{2} machines serving \alert{4} Fedora \texttt{x86\_64} workers at the
+time.  And no \emph{try builds}!
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item Initially it stored the test results in a git repository.  This
+proved too inefficient over time\ldots{}
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile,label={sec:org9dadf47}]{And now?}
+ \begin{itemize}
+\item The master runs in a dedicated VM at \alert{OSCI} (\textbf{O}pen
+\textbf{S}ource \textbf{C}ommunity
+\textbf{I}nfrastructure).
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item Most of our builders support \emph{try builds}!
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item \alert{14} workers (\alert{11} machines):
+
+\pause
+
+\begin{itemize}
+\item Sergio (Red Hat): \alert{2} machines (Fedora \texttt{x86\_64})
+
+\item Alan Hayward (ARM): \alert{2} machines (Ubuntu \texttt{ARM 32} and \texttt{64})
+
+\item Rainer Orth (CeBiTec.Uni-Bielefeld.DE): \alert{2} machines (Solaris
+\texttt{amd64} and \texttt{sparcv9})
+
+\item David Edelsohn: \alert{3} machines (RHEL 7.1 \texttt{s390x}, AIX \texttt{POWER8} and
+Debian Jessie \texttt{s390x})
+
+\item Edjunior Machado: \alert{1} machine (CentOS 7 \texttt{PPC64LE})
+
+\item Mark Wielaard: \alert{1} machine (Fedora \texttt{s390x})
+\end{itemize}
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item Test results are stored directly on-disk, and “garbage-collected”
+every week (tests older than 4 months are deleted).
+\end{itemize}
+\end{frame}
+
+\begin{frame}[label={sec:orgd76b986}]{How does it work?}
+\begin{itemize}
+\item 
+\end{itemize}
+\end{frame}
+
+\begin{frame}[label={sec:orge36c4d4}]{Notifications}
+\begin{itemize}
+\item To \emph{gdb-testers}: whenever we detect a possible regression in an
+upstream commit.
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item To the \emph{author}: on \emph{try builds}, or when his/her commit broke GDB.
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item To \emph{gdb-patches}: when a commit breaks GDB.
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item Breakage notifications are usually reliable.  Regression
+notifications are not (just look at \emph{gdb-testers}).
+\end{itemize}
+\end{frame}
+
+\begin{frame}[label={sec:orgcf5098b}]{Problems and challenges}
+\begin{itemize}
+\item Racy testcases.  Perhaps the most difficult/persistent problem?
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item Lots of test messages are non-unique.  This makes it really hard to
+compare test results and find regressions.
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item Better way to store and retrieve test results (current way is
+“enough” for what we need, but it can certainly be improved).
+\end{itemize}
+
+\pause
+
+\begin{itemize}
+\item 
+\end{itemize}
+\end{frame}
+\end{document}

submit-patch.dot

@@ -0,0 +1,10 @@
+digraph submitpatch {
+	graph [ dpi = 300 ];
+	"Patch" -> "Buildbot" [label=" Submit"];
+	"Buildbot" -> "Scheduler";
+	"Scheduler" -> "Builder 1";
+	"Scheduler" -> "Builder 2";
+	"Scheduler" -> "Builder 3";
+	"Scheduler" -> "...";
+	"Scheduler" -> "Builder N";
+}