diff --git a/definition-of-done.tex b/definition-of-done.tex
index 7f3599c55fca6b1cbbefd0cd974d51c990fb1b83..3470e92d46d3a71c911fd8b537a5ab8c9ff55d5b 100644 (file)
--- a/definition-of-done.tex
+++ b/definition-of-done.tex
%% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
%% %%
%% Author: Felipe Balbi <balbi@ti.com> %%
+%% Author: Chase Maupin <chase.maupin@ti.com> %%
%% %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item A Backlog item is not Done until it has been documented. For more
details see section \ref{sec:lcpd-definition-documented}.
\item A Backlog item is not Done until it has been Submitted for
- integration upstream. For more details see section
+ acceptance upstream. For more details see section
\ref{sec:lcpd-definition-submitted}.
\end{enumerate}
\begin{enumerate}
\item There is a simple piece of code or scripting that will enable
- validation of the new functionality.
+ automated validation of the new functionality.
\item Any environment setup required to run the test code is documented
within the code itself.
- \item The test code has been provided to the system test team so it can
- be added to the automation framework.
+ \item The developer has added the code to the automation framework so
+ that it can be tested in all future kernels. The developer can
+ work with the system test team if they need assistance in adding
+ their code to the automation framework.
\end{enumerate}
\paragraph{}
works as expected and that the results can be reproduced by others seeking
to verify the functionality in their configuration.
+\paragraph{}
+This is also critical so that we can provide test reports for customers
+looking to migrate from one kernel version to another. By being able to
+show that the same tests pass in the new kernel that passed in the old
+kernel we can alleviate fears and ease the migration.
+
\subsection{Documented}
\label{sec:lcpd-definition-documented}
\item In the rare case that a development effort cannot be submitted
upstream immediately a backlog item must be created to track the
submission requirement.
+ \item When a development patch set has been submitted upstream a story
+ should be created by the developer that tracks the merge of the patches
+ into Linus' linux.git tree. This item will ensure that we continue
+ to track the progress of those patches as they go upstream. Once the
+ patches have been merged this item can be scheduled for the system
+ test team to validate the upstream driver using the automated system.
\end{enumerate}
\paragraph{}
constantly being pushed upstream. More information will be given on this,
including the role of the Product Owner in section \ref{sec:upstreaming}.
+
\section{Exceptions}
\label{sec:exceptions}
definition. Another example might be time a developer spends learning about
a new part or technology. In this case the tested and submitted parts of the
definition may not apply, but perhaps the documented section can apply by
-having the developer present a brownbag to the rest of the team about the
+having the developer present a brown bag to the rest of the team about the
new technology area.
+\paragraph{}
+Sometimes a developer may have a feature implemented but they have a
+dependency on the work of another developer being submitted first, or perhaps
+the maintainer is not ready for them to send the patches to them yet.
+
\paragraph{}
The key point here is that at any time where there is a feeling that one or
more parts of the definition of Done do not apply, this should be agreed by the
entire scrum team. It should be discussed as part of the sprint planning and
documented in the backlog item notes to make clear what is not required and
-why.
+why. Additionally there should always be a backlog item created to track the
+submission for later to make sure it does not get forgotten.
\section{Upstreaming}
\label{sec:upstreaming}
\ref{sec:lcpd-definition-submitted} for each development item
there is a requirement that it be submitted to the upstream
list.
- \item[Step 2:] For each backlog item there should be a corresponding
+ \item[Step 2:] For each upstream submission there should be a corresponding
\textbf{"Merged"} backlog item created that will track when the
- upstream maintainer has merged the code.
+ code has been merged to Linus' master branch and can be tested in
+ the Linux mainline.
\item[Step 3:] If feedback is received on the upstream submission a new
item is added to the backlog to address the feedback and create
a new submission. This item will be scheduled in the next
sprint. This process is repeated until there is no more
- feedback.
- \item[Step 4:] Once the maintainer has merged the code, the merged
- backlog item created in step 2 will be scheduled in the next
- sprint. This item should contain the task of updating the list
- of merged code to reflect that the functionality has been
- accepted upstream.
+ feedback. If feedback is received at the beginning of the sprint
+ you should respond to the feedback immediately to acknowledge that
+ it was received and if you will not be able to submit new patches
+ immediately let the maintainer know when you can.
+ \item[Step 4:] Once the code has been merged into the mainline master
+ branch, the "Merged" backlog item created in step 2 will be submitted
+ to the system test team for verification using the automated system
+ that the test code for that item is now passing.
\end{description}
\paragraph{}
\item Any delay in submitting work to the upstream adds to the
technical debt of the team in the following ways:
\begin{itemize}
- \item Before a new LTS kernel version can be released
- by LCPD all work that was developed but not
- upstreamed must be ported to the new source
- base. This technical debt has historically
- been seen to consume most if not all of the
- team bandwidth which leads to lack of kernel
- migration or dropped feature support.
\item If the architecture changes while waiting for the
work to be upstreamed then the effort spent to
develop that work is wasted and new effort must
outstanding upstreams must be increased. The impact of missing
a merge window can be huge due to:
\begin{itemize}
- \item The requirement to then carry the patch set until
- the next merge window.
+ \item The LCPD commitment for a feature to be available in a
+ given kernel version means that if we do not hit that kernel
+ version we must carry the patches until at least the next
+ kernel version.
\item If the merge window missed happens to be for the
- next LTS kernel then the patch set must be
- carried in the integration tree for the next
- year.
+ next LTS kernel then the feature will not be available on
+ a long term kernel for at least a year.
\end{itemize}
\end{itemize}