15 Apr
2010
15 Apr
'10
11:03 a.m.
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