On 21/09/10 20:38, Aryeh Gregor wrote:
<snip>
I think the correct course of action is to revamp our
review structure
so that we can return to the status quo ante of keeping deployment
roughly in sync with trunk. We should aim for all commits should be
reviewed for deployment less than a week after being committed --
perhaps just immediately reverted if they're badly flawed, but still
reviewed.
<snip>
The code review tool is a good start. Android use a similar system :
https://review.source.android.com/
It acts as a purgatory for new patches. Once reviewed by another
developer, the patch can be pushed to the release manager for approval.
To help the release manager, maybe commits should be made to branches,
reviewed and aggregated in one clean patch to be approved and then
merged. This is something really easy to do with git, you can even edit
your commit history to make it cleaner for review / release manager.
The way it works :
developer A creates a branch
- commit
- commit x 20
developer A ask for a review to developer B
- more commits by developer A & developer B
developer A create a patch with test cases, documentation and so on.
He then submit it to a special branch such as "for-release-manager".
Release manager look at the "for-release-manager" branch history. For
each commit in there he either :
- delay it for later review
- pull approved patches and push them to "trunk"
- reject the commit
This tends to raise the signal/noise for other developers as well. I am
not sure though how it can be translated to MediaWiki :-/
cheers,
--
git clone Ashar://hashar/Voultoiz