After the release

[Olaf Siejka]

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

[Aleksey Bragin]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev