Open Stack

Doug Hellmann said on Wed, Mar 04, 2015 at 11:10:31AM -0500:
> 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.

Jim said if his patch was auto-abandoned, he would not find out. There
are mail filtering tools, custom dashboards, the REST API. There are a
myriad of ways to find out, it seems false to complain about a lack of
notification if you turned them off yourself and choose not to use
alternative tooling.

I'm not saying it's perfect. Gerrit could offer granular control of push
notifications. It's also awkward to filter auto-abandoned patches from
manually abandoned, which is why I think a new flag or two with bespoke
semantics is the best solution.

> As Jim and others have pointed out, we can identify those changesets
> using existing attributes rather than having to add a new flag.

This doesn't help new contributors who aren't using your custom
dashboard. The defaults have to be sensible. The default dashboard must
identify patches which will never be reviewed and a push notification
should be available for when a patch enters that state.

It also doesn't help composability. What if I want to find active
patches with less than 100 lines of code change? I have to copy the
whole query string to append my "delta:<100". Copying the query string
everywhere makes it easy for inconsistency to slip in. If the guideline
changes, will every reviewer update their dashboards and bookmarks?

Projects have demonstrated a desire to set policy on patch activity
centrally, individual custom dashboards don't allow this. Official
custom dashboards (that live on the Gerrit server) are a pain to change
AFAIK and we can't count on new contributors knowing how important they
are. Allowing projects to automatically flag patches helps both those
who read their Gerrit email and those who rely on custom dashboards.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.