\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
    \code{Documentation/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 \code{Documentation/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
    \code{Documentation/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}
