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