Dear Melijn: I think we both know that pywiki devs don't review theirs' commits you can see tons of "new" commits in code review (current system, SVN) and beside that we can have a automated pre-commit review. like a bot that checks If the code doesn't crash and after that let the patch merges and PEP8 bot sounds good to me
Best
On 7/23/13, Merlijn van Deen valhallasw@arctus.nl wrote:
On 23 July 2013 08:02, Bináris wikiposta@gmail.com wrote:
2013/7/22 Merlijn van Deen valhallasw@arctus.nl
No, if you are member of the +2 group means you can accept and merge any patches. However, you should *not* merge *your own* patches (unless they are trivial updates, such as i18n or family files), so that other people can comment on it before the patch is merged.
By this time, trusted committers could commit ("merge") their contributions immediately. How often did we have problems because of this? Is this limitation a solution for a real problem (if so, it's good), or just a new rule to do like MW developers once we are forced to use the same infrastructure?
It would reduce the number of commits that break things (e.g. the patching story, unicode output on rewrite that broke some stuff, etc). We are already doing post-commit review, but pre-commit review means we can give our users a more stable framework.
Merlijn