Open Stack

On 11/18/2014 07:29 AM, Daniel P. Berrange wrote:
> On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote:
>> Nova currently has 197 patches that have seen no activity in the last 4
>> weeks (project:openstack/nova age:4weeks status:open).
>>
>> Of these
>>   * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks
>> status:open label:Verified<=-1,jenkins)
>>   * 60 are -2 by a core team member (project:openstack/nova age:4weeks
>> status:open label:Code-Review<=-2)
>>
>> (note, those 2 groups sometimes overlap)
>>
>> Regardless, the fact that Nova currently has 792 open reviews, and 1/4
>> of them seem dead, seems like a cleanup thing we could do.
>>
>> I'd like to propose that we implement our own auto abandon mechanism
>> based on reviews that are either held by a -2, or Jenkins -1 after 4
>> weeks time. I can write a quick script to abandon with a friendly
>> message about why we are doing it, and to restore it if work is continuing.
>
> Yep, purging anything that's older than 4 weeks with negative karma
> seems like a good idea.  It'll make it easier for us to identify those
> patches which are still "maintained" and target them for review.
>
> That said, there's some edge cases - for example I've got some patches
> up for review that have a -2 on them, becase we're waiting for blueprint
> approval. IIRC, previously we would post a warning about pending auto-
> abandon a week before, and thus give the author the chance to add a
> comment to prevent auto-abandon taking place. It would be neccessary to
> have this ability to deal with the case where we're just temporarily
> blocked on other work.

Yes, this is indeed an issue. However, couldn't we just say "Add a 
-Workflow label to avoid auto-abandon" and then have the script simply 
ignore patches with -Workflow? As you note below, it's not a simple 
thing to determine all of the patches in a series that may happen to 
have a -Workflow at the "tail" of the patch series, but it's probably 
doable with a little script-fu.

Best,
-jay

> Also sometimes when you have a large patch series, you might have some
> patches later in the series which (temporarily) fail the jenkins jobs.
> It often isn't worth fixing those failures until you have dealt with
> review earlier in the patch series. So I think we should not auto-expire
> patches which are in the middle of a patch series, unless the preceeding
> patches in the series are to be expired too.  Yes this isn't something
> you can figure out with a single gerrit query - you'd have to query
> gerrit for patches and then look at the parent change references.
>
>
>
> Regards,
> Daniel
>