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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
