[cdwg] Monitoring Ticket Progress

[Christopher J. Morrone]

On 08/08/2013 09:06 AM, Denis Kondratenko wrote:
> That how this hole thread was started - we do want to do this under CDWG and just searching right way to do it.

Great!

I believe the right way to do it is for the patch submitter to keep 
track of his/her submissions.  If a submitted patch needs attention, 
they should raise the issue in the associated Jira ticket.  I find that 
often just a friendly reminder is all it takes to get attention on a 
patch, or an explanation of why the patch needs to wait.

If that does not solve the problem, the next step is to raise the issue 
on the CDWG mailing list.  List the specific patch(es) that you think 
need attention.  We will discuss and come to a decision together.

Lets try it out with the list that you supplied:

 >> http://review.whamcloud.com/#/c/3553/

Landed on master, August 6, 2013.
No action needed.

 >> http://review.whamcloud.com/#/c/3277/

Landed on master, June 21, 2013.
No action needed.

 >> http://review.whamcloud.com/#/c/5213/

-1 code review from Andreas, 30 inline comments.
Waiting on Xyratex to fix and push next version for review.

 >> http://review.whamcloud.com/#/c/4372/

Landed on master, June 13, 2013.
No action needed.

 >> http://review.whamcloud.com/#/c/4641/

Landed on b2_1, May 20, 2013.
Out of scope for OpenSFS "tree contract", but nevertheless, no action 
needed.

 >> http://review.whamcloud.com/#/c/4664/

This is probably a good example of one that has sat a while.  We could 
chat about what happened here.  If you go to the associated jira ticket:

   https://jira.hpdd.intel.com/browse/LU-2377

it seems clear to me that Intel's opinion was that upstream ext4 was a 
more appropriate place for this patch than carrying it in the ldiskfs 
patch stack.

Conversation between Xyratex and Intel looks like it went nicely.

Did Xyratex follow through with sending this patch to the upstream ext4 
developers?

 >> http://review.whamcloud.com/#/c/3725/

Patch is for b2_2.  There are no community endorsed b2_2 maintenance 
releases.  No action should be expected on this patch.

If this is a problem that still exists on master, Xyratex should submit 
a patch to master.

 >> http://review.whamcloud.com/#/c/2406/

Patch is for b1_8.  There are no longer any community endorsed b1_8 
maintenance releases (some Lustre vendors offer their customers 
maintenance releases as they see fit).  No action should be expected on 
this patch.

-----

That is how I would envision the process going in the future.  When 
developer feels that a patch isn't making enough progress, and didn't 
get an adequate explanation in Jira, they raise here with the CDWG.  I 
will look it over as Technical Representative on the tree contract, 
along with anyone else in the CDWG that wants to contribute.

Together with the interested party and Intel, we will decide on the 
needed course of action.

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

Ok, maybe those patches are not the right ones to discuss.  But you 
really should start discussions about patches that are currently a 
problem.  Bringing a problem to our attention should not be the start of 
a war.  It should be the start of a discussion, which will result in a 
plan of action, which will guide us to a solution.

Chris


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