[cdwg] Monitoring Ticket Progress

Thu Aug 8 04:10:03 PDT 2013

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://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> 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>
> 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>
>> 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
>> 
>> ------------------------------
>> _______________________________________________
>> 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/20130808/ff854c8f/attachment-0002.htm>