Andrew Faulds wrote:
Yes. We need a "Linus Torvalds" for ReactOS. If it worked for Linux, it'll work for ReactOS.
No. A "trunk manager" selecting what he likes won't work for reactos, because we just don't have enough devs for any kind of cherry picking. We need to take what we get. It would also slow down development as people are forced to wait for a single person.
Currently most devs don't even seem to like the idea of branches. It sounds like being banned from trunk. First that has to change. Ideally noone would work in trunk. Especially nasty quick hackfixes regressing the shit out of reactos and half ready drivers should really stay out of trunk.
"But if I work in a branch noone will test it then"... Seriously, the "Commit and force everyone else to fix it" mentality is not how we can work any longer. We have testers. And they are very well able to test branches and they are able to track down guilty revisions in a branch as well. Cases where something works perfectly fine in the branch and then mysteriously starts failing when being comitted to trunk should be very very rare.
Currently, when someone detects a regression, he says "hmm. xyz doesn't work" in #reactos-dev. Some days later it gets confirmed by someone else. Then someone writes a bugreport. That's it. But we can't continue as if nothing happened.
What we need is more responsibility. IMHO we need a "zero-regressions" policy for trunk. Yes, even the best tested code can cause regressions, but if something regressed, then the guilty commit needs to be detected asap and either fixed or reverted. Accumulating regressions will always lead to discouragement and slowed down development. Of course there are cases when a fix might judge a smaller regression. These can be announced / discussed before comitting to trunk.
My 2 cents, Timo
PS: I'm for a feature freeze until all regerssions are solved