[ros-dev] Regression fixing

[Aleksey Bragin]

On Apr 30, 2010, at 3:51 AM, James Tabor wrote:

> On Thu, Apr 29, 2010 at 5:45 PM, Olaf Siejka <caemyr at gmail.com> wrote:
>> The most important reason for moving development into branches was to
>> minimize the effect of prolonged trunk breakage, that has to  
>> happen with
>> rewrites. This is a vital issue, as inability of testing trunk on  
>> the daily
>> basis is very often a seed for regression accumulation.
>>
>
> If we had one hundred or more full time developers, this might work.
It's important to be ready right now, not in some distant future  
which may never come. We have quite a few developers already. It's  
just a matter of time when we reach 100 devs, 200 devs, etc milestones.

> We don't so it's not working and it is creating a mess and losing the
> little time we have in branches. The argument that was pushed and
> posted by the developers that left the project recently objected to
> dividing resources in regards of the other project branch (which
> should have remained as a research project and not the official
> replacement of a ReactOS subsystem) thus proving them correct.
Please be specific, no water. Who left and why?
ReactOS is an international project, and it has to be managed. If you  
don't like the existing way - try to do better, but be a teamplayer  
like you always were in our team. I don't know what happened to you  
in the last year.

Have a look at the successful, very big (bigger than ours) project -  
KDE. This is from their Code of Conduct (Capt. Obvious skips the "Be  
respectful" part), please ready very thoroughly:
"Be pragmatic
KDE is a pragmatic community. We value tangible results over having  
the last word in a discussion. We defend our core values like freedom  
and respectful collaboration, but we don't let arguments about minor  
issues get in the way of achieving more important results. We are  
open to suggestions and welcome solutions regardless of their origin.  
When in doubt support a solution which helps getting things done over  
one which has theoretical merits, but isn't being worked on. Use the  
tools and methods which help getting the job done. Let decisions be  
taken by those who do the work."

This works for them, and is reasonable. They target real result, less  
amount of bugs and less regressions. They are not afraid of doing  
bugfixing weeks, regression chasing. If you are unhappy even with so  
small(!!) step I just did, I strongly suggest to carefully think, and  
review your earlier magnificent contribution to ReactOS project.

I will repeat myself, I don't recognize you. Previously, in early  
years, you were spending days and weeks testing stuff before  
commiting, and it worked really well. Now you just fire off the  
commit and blame the kernel in any possible bug. That's not how our  
team is going to work.


> Look at this as a signal warning before the shit hits the reef.......
> The ship has turn into the reef!
No need to give false signals here, they often lead to loss of  
investment (example from stock trading area).


WBR,
Aleksey.