[cdwg] Monitoring Ticket Progress

Thu Aug 8 11:19:48 PDT 2013

Denis

Yes, absolutely, this thread has spawned from the CDWG meeting two weeks
ago. I hope that this discussion is proving useful in working through some
misunderstandings, evaluating priorities and giving those not able to make
the call a chance to participate in the discussion.

Regards

Peter

PS/ Perhaps I will see you at LAD again this year?

On 8/8/13 9:06 AM, "Denis Kondratenko" <denis_kondratenko at xyratex.com>
wrote:

>That how this hole thread was started - we do want to do this under CDWG
>and just searching right way to do it.
>
>E-mailing list was very simple suggestion.
>
>Then we started to think about that generally - gerrit searches and not
>only Xyratex ticket.
>Then I come with my suggestions about process and etc.
>
>Seems that we will start with simple list before CDWG and discussed,
>maybe later we will come with more general way. But not bad to know all
>possible ways.
>
>Thanks,
>Denis
>
>On 8 авг. 2013, at 18:08, "Jones, Peter A" <peter.a.jones at intel.com>
>wrote:
>
>> Thank you for providing a list. Seeing your examples really helps me to
>>understand the source of the disconnect.
>> 
>> This list contains several examples of patches pushed against
>>maintenance branches. I think that this is one of the major sources of
>>the communication breakdown.
>> 
>> The focus for upstreaming is master. We create maintenance releases for
>>our customers and rather than do continuous landings as we do for
>>master. We only land to maintenance branches shortly before we plan to
>>issue a release on such a branch, and landings are limited to fixes that
>>are needed by our customers.
>> 
>> This same misunderstanding has come up a number of times with Xyratex
>>which is why I specifically called it out below.
>> 
>> I also do not want this to be an adversarial discussion, but my feeling
>>is that if you reset your expectations regarding patches pushed against
>>maintenance branches, are clear about significant release dates (feature
>>freeze  etc) and you take a fresh look at the data, then you should have
>>a different take on the situation.
>> 
>> I am not claiming that we are saints either – it is true that the flock
>>patch (now landed, thankfully) did take a long time to land, for
>>example, but - rather than your initial statement that delays of 3-6
>>months being commonplace -what I see is that there can be delays of a
>>couple of months for reviews at busy times (and conversely, multiple
>>month periods for submitters to respond to review feedback), and there
>>is the occasional "difficult" patch that we are more cautious about
>>landing.
>> 
>> What is puzzling to me is, given the evident strength of feeling you
>>have had about this situation, why were none of the below examples ever
>>raised during CDWG meetings? If that had happened then we should have
>>been able to have corrected misunderstandings long ago and perhaps been
>>able to more quickly come to an acceptable approach for more
>>"problematic" issues like the flock patch.
>> 
>> I appreciate that the meetings are not at a convenient time for you
>>personally, but Chris keeps good meeting minutes at
>>http://wiki.opensfs.org/Community_Development_Working_Group and I
>>encourage you to ensure that the Xyratex representative in these
>>meetings is representing anything that you want to raise.
>> 
>> 
>> 
>> 
>> On 8/8/13 4:10 AM, "Denis Kondratenko"
>><denis_kondratenko at xyratex.com<mailto:denis_kondratenko at xyratex.com>>
>>wrote:
>> 
>> Hi Peter,
>> 
>> I wasn't been searching for gerrit (search isn't brilliant and I can't
>>build search that will show me tickets that were under review for long
>>time, I need to go to each ticket and check), just looked to my stared
>>changes, issues that I had some internal relation.
>> Couple of examples:
>> 
>> http://review.whamcloud.com/#/c/3553/
>> http://review.whamcloud.com/#/c/3277/<http://whamcloud.com/#/c/3277>
>> http://review.whamcloud.com/#/c/5213/
>> http://review.whamcloud.com/#/c/4372/
>> http://review.whamcloud.com/#/c/4641/
>> http://review.whamcloud.com/#/c/4664/
>> http://review.whamcloud.com/#/c/3725/
>> http://review.whamcloud.com/#/c/2406/
>> 
>> Again, I don't want to start any war or discussion about those tickets,
>>or about some other.
>> I don't want to blame anyone about something. But for me obviously some
>>problems exit.
>> 
>> Those tickets are probably all have good explanation why.
>> My suggestion was to build process, that will resolve such issues
>>automatically and will provide us stat and info about Sustaining review
>>activities.
>> What I don't want is to do it manually.
>> 
>> What we propose is to define all stages of Sustaining process to gather
>>all needed info to understand where we have most problems:
>> * review resources
>> * incorrect test failures
>> * rebases
>> * code freeze
>> * some other…
>> 
>> Process for all, not just Xyratex, but for all reviews.
>> 
>> That will give us more visibility and possibility to improve.
>> We are not saint and we need to improve too. We have issues with
>>upstream submission too and there are no fault here in this discussion.
>> 
>> Right now we know that only based on our experience in our heads,
>>intuitively.
>> 
>> Of course we could use any suggestions. If we all think that just
>>e-mail with list will resolve this situation - we will use that.
>> 
>> I just started this topic to share our process that could be useful,
>>and gather other feedbacks - what could be done.
>> 
>> Thanks,
>> Denis
>> 
>> On 7 авг. 2013, at 19:07, "Jones, Peter A"
>><peter.a.jones at intel.com<mailto:peter.a.jones at intel.com>> wrote:
>> 
>> Thanks Denis I would appreciate it. I absolutely agree that this needs
>>to
>> be an iterative process and that we need data to analyze and improve.
>> 
>> The last time this concern was raised (just before ISC) I did complete
>>an
>> analysis of every single Xyratex patch submitted against master and
>>(other
>> than a couple of feature patches that had been delayed by the 2.4
>>feature
>> freeze) the longest wait that I saw at that time was only a few weeks.
>> 
>> Xyratex committed at that time to provide a consolidated list of issues
>> that are a concern. I suggest that we focus on that as a first step
>>before
>> getting into possible process changes so that we can be sure that our
>> process reflects the actual situation.
>> 
>> 
>> On 8/7/13 8:11 AM, "Denis Kondratenko"
>><denis_kondratenko at xyratex.com<mailto:denis_kondratenko at xyratex.com>>
>> wrote:
>> 
>> OK, I will go and try to search.
>> 
>> Maybe I have overestimated that, my apologize for that - will provide
>>you
>> numbers and examples.
>> Point wasn't in that.
>> 
>> Point was - we have no numbers - so nothing to analyze and improve.
>> 
>> Thanks,
>> Denis
>> 
>> On 7 авг. 2013, at 18:03, "Jones, Peter A"
>><peter.a.jones at intel.com<mailto:peter.a.jones at intel.com>>
>> wrote:
>> 
>> <snip>
>> 
>> 
>> It is not a rare occurrence - patches that were submitted 6-12 months
>> after it was first pushed for review.
>> 
>> Denis, please give me three examples where patches pushed to master have
>> waited 6-12 months after being pushed for review?
>> 
>> I take this very seriously.
>> 
>> There are certainly busy times when lower priority patches might need to
>> wait but I have not seen anything that long.
>> 
>> Feature patches submitted during the feature freeze, but that is usually
>> more like 3-4 months in the worst case scenario.
>> 
>> Sometimes people push patches against maintenance branches, which can be
>> useful for the community but if these land it will only be at the time
>> we
>> create a maintenance release against that branch.
>> 
>> 
>> 
>> 
>> --
>> 
>> 
>> ------------------------------
>> For additional information including the registered office and the
>> treatment of Xyratex confidential information please visit
>>www.xyratex.com<http://www.xyratex.com>
>> 
>> ------------------------------
>> _______________________________________________
>> cdwg mailing list
>> cdwg at lists.opensfs.org<mailto: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<http://www.xyratex.com/>
>> 
>> ________________________________
>
>
>-- 
>
>
>------------------------------
>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