Richard wrote:
I agree with your points, and i'm not saying that
devs shouldn't be
allowed to work on a given featureset, i just believe that we should
be focused more on the goals for the next release.
Richard
If the devs suddently feel a motivation to fix something completely
unrelated, or to implement it, you have two choices:
1) Let them use that sudden rush (I'm sure you know the rush when you
REALLY feel like coding something) to do something useful, even if it
won't be used until ReactOS 0.99
2) Tell them to stop. In which case not only do you piss them off, but
you also lose that great code they were about to write.
The main reason why so many of the win32k rewrites ended was because
people kept telling the developers doing it to give up, continue later,
or focus on other tasks. I think we should be encouraging Gunnar, not
crticising him.
And sorry if this sounds harsh Richard, it's not directed only to you,
and in many ways I agree with your points... I've often thought like
you, until I imaginzed myself in the other situation, where I'd be the
one told to do something else... as frusrating as it is when behaving as
a "Project Manager", it's a godsend when thinking in a Developer's
mindset.
We do however have some measures in place to ensure that total chaos
does not happen. One of them are blockers before releases, which most
devs seem to be interested and actively participating in. And then there
is also a more extreme measure that a lot of the devs agree on, but
hasn't really been put in place, which is to be able to lock the tree
temporarily if 3 or more developers designate a certain bug as
hyper-critical. I believe Casper will now jump in and start ripping this
idea to shreds, but I've talked to many other developers who agree to
it... Even if implemented however, it will probably never be used unless
something massive is going on, in which case the devs would probably
focus on it out of their own good will.
Best regards,
Alex Ionescu