definition-of-done: update based on planning meetings
authorChase Maupin <Chase.Maupin@ti.com>
Thu, 30 May 2013 19:56:21 +0000 (14:56 -0500)
committerChase Maupin <Chase.Maupin@ti.com>
Wed, 12 Jun 2013 19:52:47 +0000 (14:52 -0500)
* Update the Author
* Remove reference to integration to clarify upstream kernel
* Update tested requirement to make sure developers know they
  need to add their code into the automation framework.
* Add paragraph detailing the need for test reports
* Add outline of upstream flow and creation of merge stories
  to track that items have upstream merges pending
* Clarify some reasons why the upstream step may not occur and
  what to do in that case
* Give ideas about how to handle feedback within the current
  sprint when the feedback requires changes that need to be
  scheduled in the next sprint.
* Remove the reference to backporting for LTS
* Specify that when we miss a commit we have to carry the patches

Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
---
* Updated in version 2
    * Fixed grammatical error pointed out by Felipe

definition-of-done.tex

index 85b569166aa0573a2eeadab724d1a6d2819f89f4..3470e92d46d3a71c911fd8b537a5ab8c9ff55d5b 100644 (file)
@@ -3,6 +3,7 @@
 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
 %%                                                                       %%
 %% Author: Felipe Balbi <balbi@ti.com>                                   %%
+%% Author: Chase Maupin <chase.maupin@ti.com>                            %%
 %%                                                                       %%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -93,7 +94,7 @@ definition of Done can be broken down into the following main parts
     \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}
 
@@ -115,8 +116,10 @@ people this section will detail what we mean when we say tested.
           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{}
@@ -124,6 +127,12 @@ The goal of the tested requirement is to make sure that the delivered feature
 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}
 
@@ -179,6 +188,12 @@ requirements have been put in place.
     \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{}
@@ -197,21 +212,21 @@ developer acting in the role of an upstream maintainer may not use the above
 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 implement a feature in the Integration kernel one
-way but need to change it due to architecture changes or other reasons for
-upstream.  In this case the upstream item may not be appropriate for the
-Integration requirement.
+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}
@@ -240,19 +255,22 @@ seek to balance these two requirements.
                \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{}
@@ -284,13 +302,6 @@ tasks above all other tasks.  The product owner must understand the following:
        \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
@@ -301,12 +312,13 @@ tasks above all other tasks.  The product owner must understand the following:
                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}