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(a)arctus.nl> wrote:
On 23 July 2013 08:02, Bináris
<wikiposta(a)gmail.com> wrote:
2013/7/22 Merlijn van Deen
<valhallasw(a)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