From a personal perspective, the fact we have so much code to review
in the Gerrit code review queue makes it harder for __me__ to prioritise the important patchsets and thus review them. I would hazard a guess that such a system would help work out which patches are important and which are just nice to haves/controversial and would actually lead to a more healthy code review system.
If something has a -1 or -2 it needs work. No arguments. Either work on it or abandon it and come back to it later.
As Brian says patches can be resubmitted, abandoning is a bit of a strong word, it just removes them from the review queue making it easier for other people's code to get review.
I think we should try this approach, see how it works, collect feedback from developers and revisit it in a month to see if the situation is even better.
On Wed, Apr 9, 2014 at 9:04 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 09/04/2014 17:39, Liangent a écrit :
I have some changesets where I uploaded a reworked patchset several weeks or even months after an original -1 was given...
Anyway a changeset can be easily "renewed" by rebasing it, but the side effect is that all existing -1's get flushed. If people start to use this method to extend the period, it's not something good...
OpenStack have a script which reapply all votes when a trivial rebase is detected.
Our bug is https://bugzilla.wikimedia.org/show_bug.cgi?id=41074
Apparently we can now confiure labels to recopy on trivial rebase or when no code change (ie only commit summary is changed)
Doc:
https://gerrit.wikimedia.org/r/Documentation/config-labels.html#label_copyAl...
Lets follow up on bug 41074 mentioned above.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l