Starting a new development/release cycle is the best moment for winesync to be performed. Syncing early will give us much time to find and wipe all Wine-originated bugs, which are simply unavoidable. The Winesync itself should be spreaded to as many revisions as its possible/feasible, as it will help out testers to regress-test any issues more precisely.

Now guys, i know i`m repeating myself, but please be warned that i will not drop this issue. The way our project is handling patches from outside is absolutely counterproductive. This is the only way new devs can be recruited and get commit access, but delays in reviewing and even reacting to patches is disgraceful. We are driving away potential newcomers, something no one should wonder about, if it often takes months for someone to write down a simple question about the patch content... We are risking a potential project dawnfall if we continue doing this way. I know you are busy with real life, project and other stuff, but seriously, this approach will only make things even more difficult. I did all things i could think of to help you out. Patches are now clearly tagged, listed in accessible way ( http://www.reactos.org/wiki/Bug_Filters ), i even tried to filter them, moving old and questionable stuff into separate directory (WIP aka Work in progress). Right now i took the more direct step of assigning patches to devs personally. It might be questionable, please react in such cases and comment, i will gladly relocate, but please do react. Due to Daniel recent issues and lack of free time, i volunteered for commit translation patches, at least those that can be done easily. Next thing planned here, is a builder dedicated to patch testing, but this is just a rough plan for futher discussion. I would be grateful for ANY feedback from you, perhaps some things could be done better/differently.