On Fri, Apr 27, 2012 at 10:28:54AM +0200, David Kastrup wrote: > There is no reason whatsoever that this should only be done by a single > person.
Totally! > I would expect that _every_ person contributing more than two > patches per month should be able, after uploading a patch, to be running > test-patches.py and thus emptying the queue. Could do, although I'd rather if somebody other than the original submitter gave the ok for a patch. That way there's a fresh pair of eyes looking at any differences, which would ideally make the original submitters be more clear in the commit message about any intentional changes to the regtests. > b) the queue does not build up > c) it is not always the same people who get stuck with testing > d) he can be more nonchalant about testing his submission in advance > since a bad test upload mostly implies more work for himself, and > then not all that much. I really like those possibilities, though. I still think we should track Patchy responses, though. I mean, have a completely automated system which tracks your karma. For each patch, - fails to apply to master: -10 karma (with an option to cancel this penalty if master was updated after somebody submitted their patch) - fails to compile: -5 karma - has unintended regtest differences: -3 karma - has un-notified regtest differences which are accepted as ok after some discusion: -1 karma. (yes, we want to penalize people for not mentioning those differences up-front in the git commit message!) - passes test without problems: +1 karma Then we'll have hard numbers on which developers are abusing the process. I mean, sure, we all know whose patches tend to be great and whose patches tend to be problematic... but a completely automated, objective approach would remove any personal bias. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel