A proposal was made to do winesyncs before a release to force the project to do a better job keeping things in sync and perhaps do a better job making syncs feasible/less time consuming. Rejected by plurality of votes.
Questions about how/whether to continue the driver signing program was raised. An advisory vote was held and the majority wished to continue it in one form or another. Feedback based on the advisory vote was incorporated into revised guidelines posted on the Driver Signing wiki page. New projects are now required to find a sponsor ReactOS "core developer" willing to audit their code if they wish to get their driver signed.
Decision to integrate arwinss into trunk under a separate directory structure and make it a compile-time option. Passed by majority vote.
Decision to switch main Linux build server to use cmake. Passed by majority vote.

1. The build environments for both Windows and Unix have gone through several release candidates and are effectively finalized. For the Windows BE an installer release client using MSI instead of NSIS also needs to be prepared. Minor problems still seem to exist on Mac OS X when using a combination of GCC and LLVM, but these were deemed non-blockers. Building ReactOS using CMake has been reported to take more time than using rbuild, though developers are still working to verify and determine the cause. Current theory is related to changed debug format and more thorough dependency checking by CMake. At present the plan is to put the build environment release candidates on the Linux build servers and determine if there are any problems. The Windows build servers have already been running the new build environments for testing purposes.

2. Due to the significant number of regressions and overall bugginess of ReactOS' current state, release scheduling has been deferred until the next meeting. A list of regressions and bugs has already been compiled and the team intends to work its way through the reported issues in the meantime. At the next meeting, the OS' state will be re-assessed to see whether a release is viable or not.

3. Most of the modules needed to bridge Drupal with things like Bugzilla have already been completed. To speed the transition, a decision was made to retain the current website design. Once the transition is complete, the web team can go back to updating the site's theme. Desired content changes will also not block transition to the new backend. No timetable was given for when the transition would happen.

4. For a while the project adopted the goal of targeting the Windows 2003 kernel and the latest version of Windows for user mode components. Several developers however raised objections to this and presented examples where this methodology does not work. A specific example involved symbolic link support, which required Microsoft rearchitecture not only NTFS but also the kernel's security systems. Its addition in ReactOS, assuming it is done correctly, would require changes to the kernel to adopt features from the Vista kernel, thus violating the kernel target. With these considerations, the project has decided to set both the user and kernel targets to Windows 2003. Dependency on Wine for many user mode libraries actually complicates this, as Wine has been adding Vista and later APIs without proper segregation and the developers will need to figure out how to deal with this in the long run.