> Of the few people who did respond (both in this thread and commenting > to the stack & tile commits in trunk), there was concern about coding > violations. So, addressing that seems to be a good next step, even if > it's checking out the stack-and-tile branch, making patches for it, > and submitting them on Trac. The whole aim behind the stack-and-tile feature branch creation was to actually avoid this submit patch step, by allowing Hong to work on it without having us looking over his back, until the conditions to merge back into trunk are all green, coding style included. I fail to see a point in keeping a patch submission process, which needs a review too, on a dedicated branch... Either we allow temporary code violation and design issues in a branch and only review when merges are/will be done in trunk, or we don't even allow branch to be in bad shape, and the patch submission for new feature of a critical component (app_server here) needs to define a actual review process. Which I'm not good at, as proven many often, but others more skilled may not have time to do patch after patch, either. Can't we grant Hong svn access and let him work on his branch until he'll say "I think I'm ready to merge it, can someone review now?" ? Philippe.