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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
