planetmaker wrote:Cirdan,
if you believe that single patches from your queue are fixes for trunk on their own accord and independent of the giant patch queue: then please come forward, submit them each as separate trunk patches to our issue tracker. That then has several advantages:
* allows independent review of each of them
* and ensures that they're not somewhere deeply burried inside a patch pack queue in a topic which likely will not be thought of when someone decides to look at and review "what patches and improvement suggestions do we have suggested?".
* lowers the psychological entry barrier quite dramatically as opposed to "find what suits you in 300-odd patches"
EDIT: I see that you made a nice patch queue and all, attached here in the postings. Still, if you want something particular from within that queue in trunk and reviewed: consider to also make it easy for us. And easiest is if it's broken down to one issue per independent problem. And in our issue tracker. Esepcially for big projects it makes perfect sense to reduce the overall project by these means to their real core. Getting tiny parts done piece by piece ahead of them as far as possible.
From my point of view, it is not as if opening patch tickets at the bugtracker makes much difference, usually. Take, for instance, my patch to close airports: its
flyspray task remained open for over 4 years, mostly ignored, until it was eventually applied. My patch to upgrade airports has not had such luck. It
received some attention for as long as you could find bugs in it, but, after that, it has not seen any actual review activity: neither accepted nor rejected, and no replies to my comments, just cast into oblivion. A tiny patch I wrote to align towns took
more than 2 months to be noticed, and I feel it was applied only because PhilSophus took it upon himself to champion it with you. Lastly, my depot-upgrade patch, which I
published a year and a half ago, is still waiting for its first comment by a dev. It is easy to get the impression that you ignore flyspray tasks unless they are bug reports.
Now, you come up and ask me to post my patches there, so it is easier for you to review them. But the thing is, given my past experience, I wonder if it is worth the hassle. For me, posting a patch here or at the bugtracker implies a strong commitment to actually support it and address all issues raised (or, at least, give an explanation of why something cannot be done or is not worth the effort), and not drop it lightly. It is rewarding to see the response here at the forums, where people help by adding suggestions, reporting bugs, and generally contributing to make patches better. The situation at the bugracker, on the other hand, is disheartening at best. This makes me think that you do not give much value to contributions, and this feeling is backed up by the fact that the OpenTTD web page, unlike most free software projects, has no mention whatsoever of what to do to send in patches, only bug reports.
So, it strikes me as surprising that you now tell me that I should post my patches at flyspray. What would be different this time? Why are so many tasks, not just mine, ignored on flyspray? These are honest questions: I am trying to understand how you deal with the bugtracker, because at the moment I cannot.
3298 wrote:Tha AI probably does not directly crash the game, I rather think the crashed trains do. But it also could be something different.
Now, that is a different matter. I never really tested crashing trains, so there may be bugs lurking in that area. I am still hunting for some NewGRFs in your game, but at least I know I will not have to also download the AIs.
ChillCore wrote:I did notice that you have split up patches to the extreme and perhaps the devs would want some of those patches bundled.
In general it is prefered to have patches split up, but maybe not to this point. Let's just wait and see what Devs say after submitting the first few.
There is a simple rule for this: Squashing is easy, splitting is hard.
If at some point you decide that a few commits are so small that it would be better to merge them, then it is trivial to do so (git even has options for that). On the other hand, if you decide that a commit is too large and would rather split it, that is a lot harder. Therefore, I always tend to err on the side of making too many patches, rather than too few.