[cdwg] Monitoring Ticket Progress

Wed Aug 7 05:15:56 PDT 2013

We aren't stop tracking, ticket will be in the Upstream state until it will not be submitted to master.

There is no sense for us to track same stages for upstream patch (and actually we couldn't influence to process here), because our own just passed testing and review and was committed to our sources .
There is still case that patch will be changed during Upstream phase, in this case we are transferring ticket back to Landing and picking up community commit instead of our to have unified source base.

All that you are saying about patch lifetime is true, and I am not argue with that. I am just proposing to control this process somehow (now 2 ideas, we could pick one of that):
1. implement Jira process that will reflect patch state and will allow us to have clear visibility on GreenHopper with possibility to measure time and number of tickets for different stages: Testing, Review, Landing.
2. have a Gerrit searches to discuss ticket that are long time under review or ready to submit and discuss them (or part of list) on CDWG to understand why it happens and how we could improve.

First is almost the same like second but will give us more visibility and stat for CDWG discussion about Sustaining activities, and will automatically produce board and stat, when second will be done by hand by collecting lists and cut them.

Why we need to control that? Because current method doesn't work, engineers don't understand why patches aren't submitted when they were reviewed and tested.

It is not a rare occurrence - patches that were submitted 6-12 months after it was first pushed for review. There obviously were some issues with patch and there were 2-5 cycles of review. But because review takes long (or for some other reason, like rebasing and etc) it could take 5 cycles* 2 months = 10 months to close the gap in the code.

Proposition is to get that under control and check areas for improvement. Gather some stat and understood how it could be improved or what is done wrong on both sides.

Thanks,
Denis

On 7 авг. 2013, at 11:51, "Dilger, Andreas" <andreas.dilger at intel.com> wrote:

> 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
> 
> 

-- 

------------------------------
For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com

------------------------------