We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

I realize it's a volunteer effort, but there's little more frustrating than a bug database with multi-year-old bugs to which the developers haven't even responded. If you don't have the resources to take things seriously, how about posting a banner around libsdl.org asking for help?

I realize it's hard to write software that runs on a diverse set of hardware since you can't own all possible hardware. But that's no excuse for ignoring bug reports. You can communicate with the reporters (who presumably has the hardware) to try to help them investigate the problem.

I realize some bug reports are bad reports, missing important details needed to reproduce the problem. That's no excuse for ignoring them either. Ask for details until you get the information you need.

Bugs shouldn't languish for months in the NEW state (with no replies) or the WAITING state (despite additional information being provided months ago). Why aren't the bugs at least being /assigned/ to people instead of sitting in NEW-state limbo? If there are no developers for a particular bug, how about asking in the forum for somebody willing to take it on?

I'd post in the forum myself, but my request for membership has also been languishing without a response...

Finally, the documentation for SDL is absolutely terrible. This hurts both the users and the developers. Users have a hard time using SDL and developers have a very hard time making correct, verifiable changes to SDL (or getting involved in the first place) because there is no documentation as to what the correct behavior is supposed to be, how the numerous coordinate systems and measurements interact, etc. How about insisting that code submitted to the system be documented?

I used to share your frustration, so I did the logical thing and became a contributor. 

Numbers wise, there's 2542 bugs with 474 still open, that's over 80% of the reported bugs fixed, not bad for a small team handling the most diverse sort of fuzzy bugs you can probably imagine. It's certainly not ideal, but it's also clearly not the bleak picture you are painting.

Speaking out of my own personal experience, bugs that get filed with a solid test case, bugs that get filed with a tentative patch, bugs that happen to fall dead center in the area of expertise of one of the contributors do get answered and solved in a timely manner. There are gaps of course, so I'm looking forward to what gaps you can fill.

Finally, if you find a particular bug or bugs more frustrating than the rest, feel free to email me or any of the other devs about it directly.

I would gladly become a contributor. However, SDL doesn't lend itself to understanding or changes by the uninitiated because of poor documentation. I could make changes to the code to "fix" the bugs I've reported, but without really understanding how things are supposed to work I'm afraid I'll just make things worse. (There doesn't seem to be much of a review process in place to prevent bad changes or educate developers about how things should be done, and whatever process there is seems overly lenient, as I've seen seemingly poor changes being given the okay.) I'd be willing to write the documentation myself, but I can't do that without understanding how things are supposed to work.

For example, what is the interaction between viewports, clip rects, logical size, coordinate scaling, HighDPI mode, window size, output size, and draw size? How do changes to these properties affect the other properties, and the input coordinate system and its mapping onto the output coordinate system? How are they supposed to change when a window resizes or a render target is changed or a window is moved from a HighDPI display to a regular display? This is important stuff to know for writing correct code (both inside and outside SDL), and it's hard to figure out what all the interactions are /supposed/ to be by looking at the code, let alone the documentation, which says almost nothing. Somebody could write down what actually happens on their particular OS (assuming they actually have a HighDPI display, etc. to test, which I don't), but that may just be encoding OS-specific bugs into the documentation...

The bugs I find most frustrating are the ones that sound serious and have been sitting in the NEW state (or WAITING despite a reply) for months or years with little or no response (even if they don't affect me personally). I feel like somebody should just go through them every once in a while and move them along. If they don't have solid repro steps, ask. If none are ever provided, close it. I've done this with a handful of them at random, and although I got a couple 'easy' bugs resolved I can't offer much debugging advice for the harder ones since I didn't write the code or don't have the OS/hardware.

There are a lot of reasons that some bugs stay open. Some are good reasons, some are not. We do the best we can, which isn't always great.

Thank you for your input.

--ryan.

I'm reopening this because it would be nice to address some of the things Adam is concerned about.

Adam, do you have specific bugs that you'd like to have looked at?

Can you send me an e-mail at slouken@libsdl.org with your preferred wiki username and password?

The rest of your questions, how things are supposed to interact, are probably best discussed over the phone or Skype. When discussing these we should have a plan to document the answers in a way that people can use easily.

Thanks for your feedback!

Of course there are specific bugs that affect me personally, but it would be unfair to agitate for those to get any kind of priority. I'd rather see a process whereby no bugs sit around for months or years without a response, which would benefit all bug reporters. This doesn't mean all bugs would be fixed in that time frame or that QA would have to do lots of work to investigate them all. I'm fine if QA puts the onus on bug reporters to do their own investigations if possible, and I'm fine if QA threatens to close bugs without working repro steps provided in a timely fashion, so long as they move towards some kind of resolution.

This could either be thanks to a single person who moves them through the process or because the community has been given the information they need to do it themselves, like a list of who is responsible for which bits of code so anybody can confirm the bugs and assign them to the right people, etc.

The other questions I asked were just examples of some things that are important to know in order to write correct code both inside and outside SDL, and that make me hesitate to try to change SDL code. Since they were just examples, I'm not expecting specific answers.

Also, I apologize for the tone of my original comment(s).

Adam, what you want and what we want in terms of how the bug tracker should work is the same. The difference between what's desired and reality is economic resources. The resources we have are the goodwill of a bunch of people which donate developer time, and its good for most of the tasks required, but it's certainly not perfect.

Also, take this as a piece of unsolicited advice, if you were to land on any random open source community with these sort of demands and tone, you will not get the sort of polite replies you are getting here. Just saying.

With that, name which tickets are bothering you, specially if they are critical bugs, it helps us all to be reminded of those.

For what it's worth, Jen Spradlin did an awesome job on this when I was paying her , but I ran out of money and nobody has stepped up to volunteer to take care of general SDL Q/A.

Adam, please let us know if there are any issues that are blocking you.

Thanks!

Ryan and I are slowly moving through hundreds of bugs for the SDL 2.0.6 release.