[openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

Clay Gerrard clay.gerrard at gmail.com
Mon Mar 2 21:35:37 UTC 2015

On Mon, Mar 2, 2015 at 8:07 AM, Duncan Thomas <duncan.thomas at gmail.com>

> Why do you say auto-abandon is the wrong tool? I've no problem with the 1
> week warning if somebody wants to implement it - I can see the value. A
> change-set that has been ignored for X weeks is pretty much the dictionary
> definition of abandoned

+1 this

I think Tom's suggested "help us help you" is a great pre-abandon warning.
In swift as often as not the last message ended with something like "you
can catch me on freenode in #openstack-swift if you have any questions"

But I really can't fathom what's the harm in closing abandoned patches as

If the author doesn't care about the change enough to address the review
comments (or failing tests!) and the core reviewers don't care about it
enough to *fix it for them* - where do we think the change is going to
go?!  It sounds like the argument is just that instead of using abandoned
as an explicit description of an implicit state we can just filter these
out of every view we use to look for something useful as "no changes for X
weeks after negative feedback" rather than calling a spade a spade.

I *mostly* look at patches that don't have feedback.  notmyname maintains
the swift review dashboard AFAIK:


It's possible that a pile of abandonded-changes-not-marked-as-abandonded
wouldn't actually interrupt my work-flow.  But I would imagine maintaining
the review dashboard might occasionally require looking at ALL the changes
in the queue in an effort to look for a class of changes that aren't
getting adequate feedback - that workflow might find the extra noise less
than helpful.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150302/f9675e88/attachment.html>

More information about the OpenStack-dev mailing list