Hi,
I wanted to write that too, but thankfully you saved me some typing :)

Seriously, I fully support things which Olaf pointed out, and I have something more to add. 
I want to tell that this "bug fixing" period worked really great and there was no need to force a limit of any kind (such as restricting svn write access), and I really appreciate this (I put myself as an example too by dropping all non-bugfixing work on ReactOS, creating a paged heap to monitor heap access and catch corruptions, etc).

It's very important to continue working in this direction even after the release happened! Certainly, it's fine to devote some time to your featured area (be it cmake, arwinss or anything), but maintaining should always have more priority over developing new cool features (unless those features are needed to fix actual bugs, of course).


WBR,
Aleksey Bragin.

On Mar 15, 2011, at 6:28 PM, Olaf Siejka wrote:

Hiya

I would like to point out to actions in my opinion necessary to be done after the release:

1. Syncing:

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.

Before Winesync can be performed, CMake branch should be synchronized with current trunk and the revision synchronized - locked up as reference frame for any Trunk-CMake comparison tests.
We would not want CMake effort to be delayed due to any issues with WINE code in trunk.

2. Patches

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.

Thanks in advance for your comments

 

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev