[Development] abandoning stale changes on gerrit

[Oswald Buddenhagen]

On Fri, Feb 01, 2013 at 09:58:41AM +0000, Knoll Lars wrote:
> This discussion is in many ways similar to discussions on how to
> handle bug reports. I had many discussions over the years about
> whether to automatically close old bug reports (say older than a year
> or two) or not. So far there have always been people arguing against
> it because it might destroy information and the report might still be
> valid. 
> 
i think it's slightly different.
jira tasks are a todo list.
gerrit changes are a working set.
when a change gets stale solely for a lack of attention, it basically
just moves back to todo status.
this obviously cannot happen with a todo item - only the *opposite*
thing can happen: it goes unnoticed that it lost relevance.
that means that abandoning stale changes merely reflects reality, while
closing tasks without any activity has a good chance of actively
producing misinformation.

so while i think it would make sense to have some kind of cleanup
process for jira as well, it needs to look differently - it needs more
human interaction.
- we need a honest representation of default assigness. we have some
  utterly ridiculous things there currently.
  - areas which really are unmaintained should actually auto-assign to
    nobody
  - what to do with unassigned untriaged tasks? just let them rot?
- reported tasks with an assignee get a ping after a month, and a second
  one after another month
  - if no pong comes in, the task is automatically assigned to nobody
- tasks in "needs more info" state are auto-closed after two months
  (QA people are doing that from time to time already)
- accepted _bugs_ should be pinged after a year or so, _suggestions_
  possibly after two years
  - if no pong is forthcoming ... do what? i actually don't know.
    auto-closing doesn't sound right. i think it sould simply keep
    nagging (with increasing frequency) to make the assignee finally
    verify the state, and close it or post a keep-alive.

> Things are slightly different with stale changes, [...]
> So I am with Peter, that a 'Stale' state would be nice/best,

> but we don't currently have anybody who could add this to gerrit.
> 
yes, that's the main problem. the change wouldn't be terribly hard
(adding a new state to the database, adding a new button to the
UI, adding a new default filter). the next problem would be actually
deploying this, for which we simply have no active administrative
resources.

that's why i suggested utilizing the existing feature set: just
star+abandon the changes you want to mark as "postponed".

fwiw, today i learned that it is in fact possible to query change which
are starred by *others* as well, so it would be possible to do this to
see my postponed changes:
  owner:oswald starredby:oswald is:abandoned
the downside is that it is not possible to write a filter of the type
"*all* postponed changes" (because there is no starredby:owner), but one
has to wonder what value that would have - who is going to wade through
random postponed changes to find something to adopt?

> > but even the manual comments this thread has already spawned
> > feel like odd clutter,
>
well, it is clutter. but then, there is a lot of process-supporting
comment clutter on the changes anyway.

> > a literal "keepalive" on
>
fwiw, i find is sad that a competent developer would actually think that
this is an appropriate message. but then, some people are unable to
follow some simple rules for commit messages, so i guess i should just
lower my expectations.

> > Does anyone have a problem with agreeing to all treat abandoned gerrit
> > changes in this fashion? That they are merely 'not worked on', and for
> > the why (replaced, wrong, stale, lost contributor, etc.) you need to
> > actually look at it? This should also clarify that they should never
> > be deleted en masse.
> 
> Given the fact that we don't have a 'Stale' status this makes most sense IMO. 
> 
excellent.

> But if we automate this the timeout period needs to be long enough.
> 2-3 months is certainly too short, we need to be conservative with
> these kinds of automatisms. A year sounds more reasonable.
> 
i don't think this makes sense. i'd rather have a bot post a gentle ping
after the proposed 3-month timeout, and then follow through within a few
(four?) weeks.