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