[cdwg] Monitoring Ticket Progress
Denis Kondratenko
denis_kondratenko at xyratex.com
Mon Aug 5 13:05:09 PDT 2013
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.
Thanks,
Denis
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/KanbanAndScrumInfoQVersionFINAL.pdf
> > 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
> > (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(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
> >
> >
> >
> ------------------------------------------------------------------------
> > For additional information including the registered
> > office and the treatment of Xyratex confidential
> > information please visitwww.xyratex.com
> > <http://www.xyratex.com/>
> >
> >
> ------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > cdwg mailing list
> > cdwg at lists.opensfs.org
> > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org
> >
> >
> > _______________________________________________
> > cdwg mailing list
> > cdwg at lists.opensfs.org
> > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org
> >
> >
> > ______________________________________________________________________
> > For additional information including the registered office and the
> treatment of Xyratex confidential information please visit www.xyratex.com
> >
> > ______________________________________________________________________
> > _______________________________________________
> > cdwg mailing list
> > cdwg at lists.opensfs.org
> > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org
>
>
>
--
------------------------------
For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensfs.org/pipermail/cdwg-opensfs.org/attachments/20130805/80fa310f/attachment-0001.htm>
More information about the cdwg
mailing list