[cdwg] Monitoring Ticket Progress

Dilger, Andreas andreas.dilger at intel.com
Wed Aug 7 01:51:39 PDT 2013 

On 2013/08/05 2:05 PM, "Denis Kondratenko" <denis_kondratenko at xyratex.com>
wrote:

>Hi Keith,
>We are tracking ticket and not patches, actually our Jira states reflect
>patch lifetime.
>We have Gerrit for review too and engineer reflects patch review state to
>ticket state. Our Jira states are: In Progress, Review, Landing, Upstream
>Landing.
>So that states somehow cover all stages that you have described. We could
>see how many patches (ticket) and how long patch is under review, landing
>and landing upstream.
>We are limiting all stages to catch issues. Sometime ago we seen a red
>Review column and changed a process little bit to do review more
>effectively.
>Landing never had issues.
>But our Upstream column is always red.
>We actually have divided this column by swimlines(in term of
>Greenhopper): should be submitted to Upstream; was submitted to Upstream.
>They both have issues, but longest time is spent on 'was submitted'.
>We are not tracking same stages after submitting it Upstream, that is out
>of our scope.

Maybe I am misunderstanding what you are writing here, but in case I am not
I think it is a mistake stop tracking patches after they have been
submitted
upstream.  The unfortunate truth is that there are many reasons why a patch
might not be landed after it has been submitted.

The purpose of patch inspection is to find bugs, either in the patch
itself or
with potential interactions with other patches.  The testing system hits
bugs,
whether in this patch or in existing code, and this needs to be
investigated
(either to fix the bugs in the patch or in the existing code).  People are
busy
and have many priorities, so friendly reminders that a patch needs another
inspection, needs to be retested (due to a specific and properly attributed
external failure) or is ready to land will help the patch to land.

Cheers, Andreas

>On Aug 5, 2013 9:27 PM, "Keith Mannthey" <keith.mannthey at intel.com> wrote:
>
>On Sat, 2013-08-03 at 09:43 +0300, Denis Kondratenko wrote:
>> In our Jira workflow we have different states like: Open, In Progress,
>> Review, Landing and etc.
>> It is engineer responsibility to maintain correct state.
>> After engineer see that it has two +1, he/she transfers ticket to
>> state Landing.
>> Gatekeeper has search for all tickets at this state and see what is
>> ready to land. Actually gatekeeper (or other people) could subscribe
>> to search and receive e-mail with it results.
>>
>> Having different states in Jira gives us more clear vision what is the
>> state of the project and where issues are.
>> Using Kanban GreenHopper RapidBoard you even could get many
>> statistical info about time that was spend in each state and other
>> charts/stat.
>>
>> Limiting work in progress in each state you could easily see where you
>> having issues in process. BTW our UpstreamLanding column is always
>> red, that's why we always trying to find a way to improve process of
>> upstream landing.
>Hello All,
>
>I spend time working to get patches (some of my own some of others)
>landed and these are some of my observations. I see patches as having 3
>general phases of life with regards to landing on Master branch.
>
>1. The patch is created and submitted.  It also needs to have a LU and
>the patch should be linked into the LU.  Patches that are not linked to
>their LU are quite easy to overlook. It would be really nice to have a
>automatic plugin that linked all new patches to the LUs they are
>attached to but not the old spam level of information.
>
>2. The patch is reviewed and tested.  I consider this the hardest part
>of a patches life and it many cases more work that just making the
>patch.   It needs to build, pass autotest for ldiskfs and get reviewed.
>Comments and nacks are part of the review process and most patches will
>be several versions in before they are accepted, this is mostly an
>iterative process.
>
>3. The patch is landed.  With regards to Master patches this should
>really happen within a few weeks of #2 being completed.  Landing code
>that tested well a few months ago is tricky, some isolated changes might
>be safe but many patches will just not cleanly apply and with some the
>code underneath has changed are a careful evaluation is needed.  If git
>rebase fails for the patch it can't be landed by gatekeeper.
>
>Denis,
>  In your UpstreamLanding column to you know which areas are the most
>troublesome for the patches you are tracking?  Automating gatekeeper
>notifications will only help #3.
>
>
>Thanks,
>  Keith Mannthey
>  Lustre Support and Release
>
>> Kanban def:
>> 
>http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/Kanba
>nAndScrumInfoQVersionFINAL.pdf
><http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/Kanb
>anAndScrumInfoQVersionFINAL.pdf>
>> 
>https://www.atlassian.com/software/greenhopper/overview/kanban
><https://www.atlassian.com/software/greenhopper/overview/kanban>
>>
>> Maybe having RapidBoard at Intel Jira with such info for sustaining
>> will give to all of us more visibility and stat. But that requires
>> Jira workflow changes and process changes.
>>
>>
>> On Aug 3, 2013 1:27 AM, "Christopher J. Morrone" <morrone2 at llnl.gov>
>> wrote:
>>         Thanks Denis, those are some great leads!
>>
>>         I think it would be excellent to investigate one or both of
>>         those links to get gerrit enhanced to match our workflow.  I
>>         opened ticket LU-3690 as a task to track this.
>>
>>         I like the sounds of the prolog-cookbook approach.  But I see
>>         what you mean, it is not clear to me that making a patch
>>         "submitable" is sufficient to give us something that we can
>>         use as search term.  So that may make the perl "hook for a +2
>>         approval from a simple quorum of +1 votes" a better option.
>>
>>         I am not sure that I understood your final comment about a
>>         Jira "Landing" state.
>>
>>         Chris
>>
>>         On 08/02/2013 04:13 AM, Denis Kondratenko wrote:
>>                 Chris,
>>
>>                 I see your point now. We are not using gerrit with a
>>                 way it was designed
>>                 for (when +2 should be there to submit; seems our
>>                 gatekeepers doing +2).
>>                 You are right it is impossible to build search for
>>                 gatekeeper from plain
>>                 gerrit without it modification.
>>
>>                 There are still some ways to workaround that:
>>                 *
>http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review
><http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review>
>>                 (A hook could -
>>                 for instance - allow a project to install an automated
>>                 gatekeeper to
>>                 vote +2 'submit approved' when sufficient +1 votes
>>                 'looks good to me'
>>                 have been received)
>>                 *
>>                 
>http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12
>_1_1_2_code_review
><http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_1
>2_1_1_2_code_review> (but
>>                 I don't know if it will get right searches..)
>>                 * in Xyratex we are using Jira state "Landing" to
>>                 build filter for
>>                 gatekeeper.
>>
>>                 OK, even if we could't separate gatekeeper changes
>>                 from other, filter is
>>                 still useful to check issues with no feedback for a
>>                 long time.
>>
>>                 Thanks,
>>                 Denis


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division

More information about the cdwg mailing list