It would be nice to have a cronjob auto abandon changes with a negative review and no update for more than a month. Here is a query for such changes: https://gerrit.libreoffice.org/#/q/status:open+%28label:Code-Review%253D-1+OR+label:Code-Review%253D-2+OR+label:Verified%253D-1%29+age:1month,n,z The script sending the daily digest to the developers might be used as inspiration: https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=blob;f=gerritbot/send-daily-digest;h=79d86b8926ec7be8a5b9624e20e06d5c6275d85e;hb=99053ffcc1c246d9dddc8d42c1bd447dbcb196f5 see http://nabble.documentfoundation.org/minutes-of-ESC-call-td4109744.html for reference on the discussion on the ESC
exception: if a patch has been marked with negative feedback by the author of the patch himself, leave it alone marking one's patch with -2 is used to indicate a 'working' patch.. something uploaded for review/discussion purpose but not intended to be merge as is There is no reason to make these disappear
Another things: that auto purge stuff _have to_ be project configurable... gerrit is used to track MC activity for instance, and patch there must not be messed with in any way.
(In reply to comment #1) > exception: if a patch has been marked with negative feedback by the author > of the patch himself, leave it alone > marking one's patch with -2 is used to indicate a 'working' patch.. No even then. The recommended way to do a working patch is using drafts: https://wiki.documentfoundation.org/Gerrit#Submitting_patches_as_drafts Everything else is frustrating reviewers checking "open" changes. Also, even _if_ a change would still be uploaded accidentally for review although it is not intended to be merged as is, there is little harm done, when the change is abandoned under the conditions above. Reviving a abandoned change is trivial and the autoabandon is actually a helpful reminder -- better than letting them stay in limbo for months.
(In reply to comment #2) > Another things: that auto purge stuff _have to_ be project configurable... > gerrit is used to track MC activity for instance, and patch there must not > be messed with in any way. As an Easy Hack is limited to project:core for the start -- its the majority of changes anyway.
"No even then. The recommended way to do a working patch is using drafts:" I disagree with that.. quoting yourself from a wiki page does not make a 'recommended' way. Draft are a pain in the but... and when you wrote that it was not even possible to view other's draft for most people So the feature exist.. but is by no mean 'recommended'. "there is little harm done, when the change is abandoned under the conditions above. Reviving a abandoned change is trivial and the autoabandon is actually a helpful reminder -- better than letting them stay in limbo for months." Patch are presented typically from the newsest modified to the oldest modified. furthermore reviewed -2 patch are visually easy to detect so ... such patch do not actually interfere with normal reviewer works I do not see the ground to put the burden of 'little harm' to fellow committers by messing with their work just to make the main page 'look good' I'm not arguing against the clean-up of drive by patch not being worked upon.. but a patch uploaded by a committer, explicitly marked -2 by him should be left alone.
(In reply to comment #5) > I'm not arguing against the clean-up of drive by patch not being worked > upon.. but a patch uploaded by a committer, explicitly marked -2 by him > should be left alone. Not if its untouched for more than a month.
"Not if its untouched for more than a month." We do not all work fulltime on LibreOffice... a month maybe seem overly long to you.. but it is only 4 week-end... In any case what is the goal here ? If I mark a patch -2 myself, that means it is not ready, and it also mean I'm aware of it and will follow up on it... or abandon it myself if need be. Why would you want to mess with that ? what is the benefit ? The benefit from my side is the ability, for instance, to to buildbot build on an experimental thing... thing that may takes months of amateur tinkering before being in shape for merging.
(In reply to comment #7) > In any case what is the goal here ? If I mark a patch -2 myself, that means > it is not ready, and it also mean I'm aware of it and will follow up on > it... or abandon it myself if need be. Why would you want to mess with that > ? what is the benefit ? This is to prevent reviewer to run into the same unchanged patches again and again when checking on janitorial patrol. Frustrating reviewer is not something we should do as they are rare anyway. As said trying to get feedback on a self-inflicted -2 change is suboptimal anyway as a/ there are drafts for that b/ many reviewers will not even open a change marked as -2 on the overview, esp. when that change is a few weeks old The auto-abandon stops frustrating those few reviewer that do walk _all_ change (which is a good thing) and it reminds the submitters that they still have something open and it hurts the change in no way. As a casual submitter to openstack, I found the autoabandon very helpful and not at all discouraging -- rather it promotes engagement.
Ci-infra bugs are now tracked in redmine. Redmine bug #1118 https://wiki.documentfoundation.org/Category:Infrastructure https://redmine.documentfoundation.org/projects/infrastructure https://redmine.documentfoundation.org/issues/1106 https://redmine.documentfoundation.org/issues/1118 Closing this bug as MOVED.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript TopicWeb) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]