<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1251"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Many thanks, Peter.<div><br></div><div>I believe you are hitting the right points here. Collective negotiations especially using email lists and a biweekly call can be challenging to have such discussions and projects coordinate. It's an enormous challenge but the benefits of improvement are something we can all benefit from. </div><div><br></div><div>Even though attempts may have been made in the past, it's really on going process of continuing improvement. One that should be balanced and not put unreasonable pressures on your organization.</div><div><br></div><div>We all very much appreciate your efforts. </div><div><br></div><div>Cheers,</div><div>Kevin</div><div><br></div><div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">P. Kevin Canady<br>Director, Business Development Lustre and HPC Services<br><a href="mailto:kevin_canady@xyratex.com">kevin_canady@xyratex.com</a><br>O: 510-687-5475<br>C: 415.505.7701 (best)<br><br><br></div></span>
</div>
<br><div><div>On Aug 9, 2013, at 5:04 AM, "Jones, Peter A" <<a href="mailto:peter.a.jones@intel.com">peter.a.jones@intel.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Kevin<br><br>Re-reading this email sent at the end of a long day, I wonder if it does<br>not come across in the spirit that it was intended. Sorry if that is the<br>case and I will try and make amends now.<br><br>I appreciate that this is not really your area, so you must feel pretty<br>concerned to step in like this, so I really hope that I can set your mind<br>at ease here.<br><br>I think that you have picked out a very useful part of the thread. I would<br>absolutely love to have some better tools that allowed me to quickly spot<br>patterns and anomalies amongst all the hundreds of patches flowing through<br>the system. The current mechanisms are a little crude and definitely not<br>intuitive. There is also a lack of metrics for us to track our<br>effectiveness over time.<br><br>Ultimately, though, such a system is simply a tool to help us improve the<br>patch landing process itself. It will enable us to identify patches where<br>things are not running smoothly for whatever reason, review them, and take<br>corrective action. It is by this iterative process that will help us<br>improve over time.<br><br>My concern is that I do not want us to wait until we have an improved<br>tracking system in place before we start other improvements to our<br>processes. While not needing to dwell on the specifics of the tickets, my<br>takeaway was that there was low hanging fruit in this area across the<br>board, so I think that it illustrates the value of using the options at<br>our disposal today to improve things in parallel to any longer-term<br>initiative to have a more automated mechanism in place.<br><br>John Forgan of Xyratex sent out some filters which could generate some<br>possible candidates for discussion and, to my mind, each individual<br>engineer has a more manageable number of patches that they authored and<br>know intimately and so should be able to flag situations where closer<br>attention seems warranted.<br><br>Discussing such matters has been a long-standing - but rarely used -<br>function of the CDWG and I really think that we would all benefit from<br>taking better advantage of this.<br><br>I hope that this clarifies things for you. If not, then please feel free<br>to call me and let's talk this over or, of course, we can talk about this<br>on next week's CDWG call.<br><br>Regards<br><br>Peter<br><br>On 8/8/13 10:08 PM, "Jones, Peter A" <<a href="mailto:peter.a.jones@intel.com">peter.a.jones@intel.com</a>> wrote:<br><br><blockquote type="cite">Hi Kevin<br><br>I did understand what Denis was proposing and my only objection to it was<br>that it would take time to set this up and I personally feel that this<br>time could be better spent elsewhere.<br><br>I think that it is perfectly healthy to discuss this and I do not think<br>that you should feel threatened by such dialog.<br><br>In my view, this thread has been quite productive in that Denis has had a<br>flawed assumption clarified.<br><br>From what I have seen of Denis's work, I would expect him to respond to<br>that in a positive manner.<br><br>Regards<br><br>Peter<br><br>On 8/8/13 7:44 PM, "Kevin Canady" <<a href="mailto:kevin_canady@xyratex.com">kevin_canady@xyratex.com</a>> wrote:<br><br><blockquote type="cite">Chris,<br>Peter and you continue to miss the main point Denis was making. There<br>never was any implication of animosity, so no need to be defensive or<br>stir such topic. There is no conflict. Somehow, and quite<br>unfortunately, this thread continues to be stuck on the defense of<br>specific patch activity when the main point that was being made was<br><br><blockquote type="cite"><blockquote type="cite">Those tickets are probably all have good explanation why.<br>My suggestion was to build process, that will resolve such issues<br>automatically and will provide us stat and info about Sustaining review<br>activities.<br>What I don't want is to do it manually.<br><br>What we propose is to define all stages of Sustaining process to<br>gather all needed info to understand where we have most problems:<br>* review resources<br>* incorrect test failures<br>* rebases<br>* code freeze<br>* some other<br><br>Process for all, not just Xyratex, but for all reviews.<br><br>That will give us more visibility and possibility to improve.<br>We are not saint and we need to improve too. We have issues with<br>upstream submission too and there are no fault here in this discussion.<br><br>Right now we know that only based on our experience in our heads,<br>intuitively.<br><br>Of course we could use any suggestions. If we all think that just<br>e-mail with list will resolve this situation - we will use that.<br><br>I just started this topic to share our process that could be useful,<br>and gather other feedbacks - what could be done.<br></blockquote></blockquote><br>It would be extremely helpful if we can remain centered on these<br>discussions to make this a productive dialog.<br><br>Kevin<br><br>On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone <<a href="mailto:morrone2@llnl.gov">morrone2@llnl.gov</a>><br>wrote:<br><br><blockquote type="cite">On 08/08/2013 09:06 AM, Denis Kondratenko wrote:<br><blockquote type="cite">That how this hole thread was started - we do want to do this under<br>CDWG and just searching right way to do it.<br></blockquote><br>Great!<br><br>I believe the right way to do it is for the patch submitter to keep<br>track of his/her submissions. If a submitted patch needs attention,<br>they should raise the issue in the associated Jira ticket. I find that<br>often just a friendly reminder is all it takes to get attention on a<br>patch, or an explanation of why the patch needs to wait.<br><br>If that does not solve the problem, the next step is to raise the issue<br>on the CDWG mailing list. List the specific patch(es) that you think<br>need attention. We will discuss and come to a decision together.<br><br>Lets try it out with the list that you supplied:<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/3553/">http://review.whamcloud.com/#/c/3553/</a><br></blockquote></blockquote><br>Landed on master, August 6, 2013.<br>No action needed.<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/3277/">http://review.whamcloud.com/#/c/3277/</a><br></blockquote></blockquote><br>Landed on master, June 21, 2013.<br>No action needed.<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/5213/">http://review.whamcloud.com/#/c/5213/</a><br></blockquote></blockquote><br>-1 code review from Andreas, 30 inline comments.<br>Waiting on Xyratex to fix and push next version for review.<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/4372/">http://review.whamcloud.com/#/c/4372/</a><br></blockquote></blockquote><br>Landed on master, June 13, 2013.<br>No action needed.<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/4641/">http://review.whamcloud.com/#/c/4641/</a><br></blockquote></blockquote><br>Landed on b2_1, May 20, 2013.<br>Out of scope for OpenSFS "tree contract", but nevertheless, no action<br>needed.<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/4664/">http://review.whamcloud.com/#/c/4664/</a><br></blockquote></blockquote><br>This is probably a good example of one that has sat a while. We could<br>chat about what happened here. If you go to the associated jira ticket:<br><br> <a href="https://jira.hpdd.intel.com/browse/LU-2377">https://jira.hpdd.intel.com/browse/LU-2377</a><br><br>it seems clear to me that Intel's opinion was that upstream ext4 was a<br>more appropriate place for this patch than carrying it in the ldiskfs<br>patch stack.<br><br>Conversation between Xyratex and Intel looks like it went nicely.<br><br>Did Xyratex follow through with sending this patch to the upstream ext4<br>developers?<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/3725/">http://review.whamcloud.com/#/c/3725/</a><br></blockquote></blockquote><br>Patch is for b2_2. There are no community endorsed b2_2 maintenance<br>releases. No action should be expected on this patch.<br><br>If this is a problem that still exists on master, Xyratex should submit<br>a patch to master.<br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/2406/">http://review.whamcloud.com/#/c/2406/</a><br></blockquote></blockquote><br>Patch is for b1_8. There are no longer any community endorsed b1_8<br>maintenance releases (some Lustre vendors offer their customers<br>maintenance releases as they see fit). No action should be expected on<br>this patch.<br><br>-----<br><br>That is how I would envision the process going in the future. When<br>developer feels that a patch isn't making enough progress, and didn't<br>get an adequate explanation in Jira, they raise here with the CDWG. I<br>will look it over as Technical Representative on the tree contract,<br>along with anyone else in the CDWG that wants to contribute.<br><br>Together with the interested party and Intel, we will decide on the<br>needed course of action.<br><br><blockquote type="cite">Again, I don't want to start any war or discussion about those<br></blockquote>tickets, or about some other.<br><blockquote type="cite">I don't want to blame anyone about something. But for me obviously<br></blockquote>some problems exit.<br><br>Ok, maybe those patches are not the right ones to discuss. But you<br>really should start discussions about patches that are currently a<br>problem. Bringing a problem to our attention should not be the start of<br>a war. It should be the start of a discussion, which will result in a<br>plan of action, which will guide us to a solution.<br><br>Chris<br><br><br><blockquote type="cite"><blockquote type="cite"><a href="http://review.whamcloud.com/#/c/3553/">http://review.whamcloud.com/#/c/3553/</a><br>http://review.whamcloud.com/#/c/3277/<http://whamcloud.com/#/c/3277><br>http://review.whamcloud.com/#/c/5213/<br>http://review.whamcloud.com/#/c/4372/<br>http://review.whamcloud.com/#/c/4641/<br>http://review.whamcloud.com/#/c/4664/<br>http://review.whamcloud.com/#/c/3725/<br>http://review.whamcloud.com/#/c/2406/<br><br>Again, I don't want to start any war or discussion about those<br>tickets, or about some other.<br>I don't want to blame anyone about something. But for me obviously<br>some problems exit.<br><br>Those tickets are probably all have good explanation why.<br>My suggestion was to build process, that will resolve such issues<br>automatically and will provide us stat and info about Sustaining<br>review activities.<br>What I don't want is to do it manually.<br><br>What we propose is to define all stages of Sustaining process to<br>gather all needed info to understand where we have most problems:<br>* review resources<br>* incorrect test failures<br>* rebases<br>* code freeze<br>* some other<br><br>Process for all, not just Xyratex, but for all reviews.<br><br>That will give us more visibility and possibility to improve.<br>We are not saint and we need to improve too. We have issues with<br>upstream submission too and there are no fault here in this<br>discussion.<br><br>Right now we know that only based on our experience in our heads,<br>intuitively.<br><br>Of course we could use any suggestions. If we all think that just<br>e-mail with list will resolve this situation - we will use that.<br><br>I just started this topic to share our process that could be useful,<br>and gather other feedbacks - what could be done.<br><br>Thanks,<br>Denis<br><br>On 7 . 2013, at 19:07, "Jones, Peter A"<br><peter.a.jones@intel.com<mailto:peter.a.jones@intel.com>> wrote:<br><br>Thanks Denis I would appreciate it. I absolutely agree that this<br>needs to<br>be an iterative process and that we need data to analyze and improve.<br><br>The last time this concern was raised (just before ISC) I did<br>complete an<br>analysis of every single Xyratex patch submitted against master and<br>(other<br>than a couple of feature patches that had been delayed by the 2.4<br>feature<br>freeze) the longest wait that I saw at that time was only a few<br>weeks.<br><br>Xyratex committed at that time to provide a consolidated list of<br>issues<br>that are a concern. I suggest that we focus on that as a first step<br>before<br>getting into possible process changes so that we can be sure that our<br>process reflects the actual situation.<br><br><br>On 8/7/13 8:11 AM, "Denis Kondratenko"<br><denis_kondratenko@xyratex.com<mailto:denis_kondratenko@xyratex.com>><br>wrote:<br><br>OK, I will go and try to search.<br><br>Maybe I have overestimated that, my apologize for that - will provide<br>you<br>numbers and examples.<br>Point wasn't in that.<br><br>Point was - we have no numbers - so nothing to analyze and improve.<br><br>Thanks,<br>Denis<br><br>On 7 . 2013, at 18:03, "Jones, Peter A"<br><peter.a.jones@intel.com<mailto:peter.a.jones@intel.com>><br>wrote:<br><br><snip><br><br><br>It is not a rare occurrence - patches that were submitted 6-12 months<br>after it was first pushed for review.<br><br>Denis, please give me three examples where patches pushed to master<br>have<br>waited 6-12 months after being pushed for review?<br><br>I take this very seriously.<br><br>There are certainly busy times when lower priority patches might need<br>to<br>wait but I have not seen anything that long.<br><br>Feature patches submitted during the feature freeze, but that is<br>usually<br>more like 3-4 months in the worst case scenario.<br><br>Sometimes people push patches against maintenance branches, which can<br>be<br>useful for the community but if these land it will only be at the<br>time<br>we<br>create a maintenance release against that branch.<br><br><br><br><br>--<br><br><br>------------------------------<br>For additional information including the registered office and the<br>treatment of Xyratex confidential information please visit<br>www.xyratex.com<http://www.xyratex.com><br><br>------------------------------<br>_______________________________________________<br>cdwg mailing list<br>cdwg@lists.opensfs.org<mailto:cdwg@lists.opensfs.org><br>http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org<br><br><br><br><br>________________________________<br>For additional information including the registered office and the<br>treatment of Xyratex confidential information please visit<br>www.xyratex.com<http://www.xyratex.com/><br><br>________________________________<br></blockquote><br><br></blockquote><br>_______________________________________________<br>cdwg mailing list<br><a href="mailto:cdwg@lists.opensfs.org">cdwg@lists.opensfs.org</a><br>http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org<br></blockquote><br>_______________________________________________<br>cdwg mailing list<br><a href="mailto:cdwg@lists.opensfs.org">cdwg@lists.opensfs.org</a><br>http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org<br></blockquote><br></blockquote><br></blockquote></div><br></div></body></html>