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

Doug Hellmann doug at doughellmann.com
Wed Mar 4 16:10:31 UTC 2015

On Wed, Mar 4, 2015, at 07:24 AM, Alexis Lee wrote:
> John Griffith <john.griffith8 at gmail.com> writes:
> > ​Should we just rename this thread to "Sensitivity training for
> > contributors"?
> Culture plays a role in shaping ones expectations here. I was lucky
> enough to grow up in open source culture, so I can identify an automated
> response easily and I don't take it too seriously. Not everyone has the
> same culture and although I agree we need to confront these gaps when
> they impede us, it's more constructive to reach out and bridge the gap
> than blame the outsider.
> James E. Blair said on Tue, Mar 03, 2015 at 07:49:03AM -0800:
> > If I had to deprioritize something I was working on and it was
> > auto-abandoned, I would not find out.
> You should receive messages from Gerrit about this. If you've made the
> choice to disable or delete those messages, you should expect not to be
> notified. The review dropping out of your personal dashboard active
> review queue is a problem though - an email can be forgotten.

I used to use email to track such things, but I have reached the point
where keeping up with the push notifications from gerrit would consume
all of my waking time. I currently have 2931 unread messages in my
filtered mailbox representing comments only on changesets I have
submitted or reviewed, which does not include changes in repositories I
am interested in or where I am a core reviewer. I'm sure that's a small
number compared to some of our other developers more active than I am.

We all have different workflows and ways to keep up. We can't assume
that the solution any one of us uses will work for everyone involved in
the project -- we work differently and we have different scopes in terms
of number of repos we watch, or even the areas within a repository that
we care about.

Jim's proposal to provide a variation on one tool based on gerrit
queries is a small change, and seems more reasonable than what appears
socially as throwing away someone's work. Based on his arguments in this
thread, I am going to stop abandoning patches in Oslo repositories (I
was doing it by hand, rather than with a script) and start leaving
comments suggesting that authors may want to update or abandon their
patch instead. We have a good dashboard [1] set up thanks to Sean's
dashboard creator tool [2], and I use it with reasonably good results
when I sit down to do reviews.

[1] https://wiki.openstack.org/wiki/Oslo#Review_Links
[2] http://git.openstack.org/cgit/stackforge/gerrit-dash-creator

> For what little it's worth, I think having a community-wide definition
> of inactive and flagging that in the system makes sense. This helps us
> maintain a clear and consistent policy in our tools. However, I've come
> around to see that abandon semantics don't fit that flag. We need to
> narrow in on what inactive really means and what effects the flag should
> have. We may need two flags, one for 'needs submitter attention' and one
> for 'needs review attention'.

As Jim and others have pointed out, we can identify those changesets
using existing attributes rather than having to add a new flag. For
example, that Oslo dashboard includes a section for patches that haven't
been reviewed in the last 2 days and another for changes that were
submitted in the last 5 days and have no reviews at all. All of the
queries filter out patches failing Jenkins tests [3], so it's possible
for us to ignore those easily. Gerrit's query language is a bit clunky,
but it is quite powerful for building these sorts of useful views.



> Alexis
> -- 
> Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list