On Thu, Oct 29, 2009 at 11:14 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Did you actually review that patch or anyone else? Hey, at least I didn't reintroduce my old coding style violation when I applied Pete's changes on midi_server's DeviceWatcher.cpp in r33782. ;-) More seriously, and as discussed a few days ago on haiku-development (see http://www.freelists.org/post/haiku-development/Stack-Tile-update thread), the objective was that the code will then get more eyes on it and the bug will get ironed out faster if we integrate it sooner rather than later. > Besides a gazillion coding style issues, it doesn't seem to be ready > for a component as crucial as the app_server at all. It does need code refactoring and style fixing indeed, no doubt. But my main purpose for committing it was to allow people testing it (so we got report and enhancement hints) and coders working on it without having to apply the patch in a few months when they'll want to and then discover it doesn't applied gracefully anymore. > I will revert that change again. The fact that change can be commit in one single shot and impacting only src/servers/app make this action far more easer, and that a risk I ponder before doing that commit. > We can put it in a branch if you like, > but this isn't ready for trunk. Okay, I take notice. I'll create a branch for it and try to eventually fix main issues before merging back into trunk. Me or whoever want to. I didn't though it was necessary, I was wrong. Which lead me to ask if it's not the time to clarify the purpose of trunk and the commit policy there. After alpha1, if trunk is not anymore the main coding tree where changes, even pending ones, happens but is supposed to be a little more stable, policed source tree, then branches should be promoted far more often, no? Bye, Philippe Houdoin.