[cdwg] Monitoring Ticket Progress

Thu Aug 8 08:08:09 PDT 2013

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

________________________________