Beaten to a reply by dihedral. While I agree with his post I'll still leave my answer below:
vinaximus wrote:Yes, its true, the game will become buggy and unstable. I have been playing OTTD regularly since very earlier versions, and as an end user, i didn't feel that the game is buggy (like some other Open Transport games), so fixing bugs could always be second priority.
The game doesn't feel buggy
because fixing bugs has always had a high priority.
If most of the developer's patches are added soon to the existing version, the developers will be encouraged also and the users will also be happier.
If adding more patches also means introducing more bugs the end users will not be happier. Keep in mind that most of the end-users have never seen the development forum so they don't really know what they're missing out on. As such, keeping the game bug-free will result in more happy users than adding a few new features but also introducing bugs.
one patch that I feel could be integrate are : New stations GUI
And why do you feel it could be integrated? Did you study the patch to find inconsistencies and bugs? Did you look at the source code to see if any new code introduced by that patch could perhaps be coded in a more general way so it's also useful in other places? Or did you just use a pre-compiled build with that patch included and decided you like the looks of it?
MagicBuzz wrote:I just say my feeling. Some time ago I got some answers like "take care at the code style there are unseless spaces in your patch".
After 3 or 4 updates where I tried my best to remove spaces, I still got that reply.
I spent several hours doing this, where the dev could update my file in 2 seconds as he did know which spaces he didn't like.
Finaly I found that Visual Studio replaced every 4 spaces with a tab, so even after fixing the spaces manually, I still got the tabs when editing the file again.
I think this exemple is a good exemple, as the patch was very small, ready to trunk, tested, network safe, etc. but I was stopped just because 2 seconds of help a dev didn't gave me.
I hope you don't mind me taking this as example as well, but if you have trouble understanding any hints given to you, feel free to ask for a better explanation. Like in this case, if you really can't find the spaces ask for help on how to spot them (use a text editor where tabs/spaces are visualized).
The same goes for other problems, it's not doable to give a very long explanation of why something won't work every time, so we try to be as clear as possible without taking an hour for every answer. If you don't understand a reaction, feel free to ask for a better explanation.
About a patch not being accepted when the coding style (including wrong spaces) is not ok: Where should we draw the line if not at perfection? Perfectly adhering to the coding style (for every case there is a coding style) isn't so hard, and if we would accept patches that don't comply directly the code would become a mess real fast. A little space there didn't matter, so why does an extra line here? Who cares I use // in one place and /* in another to start a comment? Why care about the difference between "char *tmp" and "char* tmp"? Who cares about "int a=3+b?3:2;" instead of the version with more spaces "int a = 3 + (b ? 3 : 2);"? You see where this is going?
So why doesn't the dev fix those little problems (after all it was only a few spaces)? This time it might only be a few spaces, but if the dev fixed it your next patch would also be one with wrong spaces. And see my argument above, if he can fix some spaces why not fix some other coding style issues? And if those can be fixed, why not fix some more fundamental problems too? And before you know it, the dev who was supposed to be just reviewing your patch is rewriting it from scratch. The "your" in these lasts sentences is to be taken very liberal, and does not apply to you (=MagicBuzz) directly, but as a more general remark.
From a non-dev point of view I know how annoying it can be if you keep being told that your patch does not comply with the coding style. You could just ask TrueBrain how often my patches were wrong at first. However after some time you get used to it and patches get accepted without problems, and a while later you find yourself to be a dev.
Also please note that I have no idea who reviewed your patch and kept complaining about spaces, it might be myself or any other dev. That doesn't change my reply above in any way.
Since my reply become longer than I anticipated, I'll summarize it shortly: Reviewing patches takes time, fixing a patch from someone else takes even more time. That's why generally we try to review only and let the fixing be done by the original patch author. That way not only does he learn how to fix it, it also saves time for the dev (so he can review more patches / code more features / fix more bugs).