Hy,
The reason we asked for commits to the stable branch to be reviewed by
another person (Zend or community) is so that we have another eye on
commits that go into the stable releases. My past experience has been
that sometimes bad fixes or API breaking fixes get commited (by
accident) and I think this could help mitigate the risk.
Yeah...
I just remember the change which gavin made to the Zend_Date API which
broke the complete class where I was nearly in giving up my work for
Zend Framework. And it was a Zender who broke it. ;-)
We intentionally don't limit this to Zenders. We think anyone who is well
versed in the Zend Framework can be another helping eye on the commit.
The person will not always be an expert on your code but might be able
to catch some issues with the commit. Btw, you'd commit to trunk first
so people would have an easy time to see the commit.
I am with you in having things checked by minimum 4 eyes.
But it seems that I am the only one who has questions on the
practical useage for all... ;-)
Better to have this questions answered early than too late ;-)
In your case btw, Alex from our team would be a good person to have
review the commits but anyone is fine.
I know, otherwise I would have cc'ed my mails to another Zend'er ;-))
I know it's a bit of overhead but I think the additional process would
help make sure we release high quality mini releases. Quality is really
one of the key things which should set our project apart.
Definitly...
Just to mention:
Dont only rely on code-quality... also documentation quality should be
archived.
Many of our contributors are no english natives. We should also think about
having someone looking over documentation parts before they are integrated
Greetings
Thomas
I18N Team Leader
