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

Thierry Carrez thierry at openstack.org
Tue Mar 3 09:59:49 UTC 2015

Doug Wiegley wrote:
> [...] 
> But I think some of the push back in this thread is challenging this notion that abandoning is negative, which you seem to be treating as a given.
> I don't. At all. And I don't think I'm alone.

I was initially on your side: the "abandoned" patches are not really
deleted, you can easily restore them. So "abandoned" could just mean
"inactive" or "stale" in our workflow, and people who actually care can
easily "unabandon" them to make them active again. And since
"abandoning" is currently the only way to permanently get rid of stale /
-2ed / undesirable changes anyway, so we should just use that.

But words matter, especially for new contributors. For those
contributors, someone else "abandoning" a proposed patch of theirs is a
pretty strong move. To them, abandoning should be their decision, not
yours (reviewers can -2 patches).

Launchpad used to have a similar struggle between real meaning and
workflow meaning. It used to have a single status for rejected bugs
("Invalid"). In the regular bug workflow, that status would be used for
valid bugs that you just don't want to fix. But then that created
confusion to people outside that workflow since the wrong word was used.
So "WontFix" was introduced as a similar "closed" state (and then they
added "Opinion" because "WontFix" seemed too harsh, but that's another

We have (like always) tension around the precise words we use. You say
"Abandon" is generally used in our community to "set inactive". Jim says
"Abandon" should mean abandon and therefore should probably be left to
the proposer, and other ways should be used to "set inactive".

There are multiple solutions to this naming issue. You can rename
"abandon" so that it actually means "set inactive" or "mark as stale".

Or you can restrict "abandon" to the owner of a change, stop defaulting
to "is:open" to list changes, and introduce features in Gerrit so that a
"is:active" query would give you the right thing. But that query would
need to be the Gerrit default, not some obscure query you can run or add
to your dashboard -- otherwise we are back at step 1.

Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list