NVIDIA, bug handling, and patience

Recently, the long-time maintainer of the NVIDIA packages for Debian stepped down, after having not had much time to work on the packages for some time. I don't really like maintaining non-free packages, but I have some NVIDIA hardware and nouveau isn't quite far enough along yet for me to feel comfortable just switching, so I decided to help, despite having very little spare time. Thankfully, Andreas Beckmann stepped up and has been submitting patches like crazy, so I've not had to do a lot of the work.

This is a very difficult package to maintain, since it's completely non-free. Nearly all the code is a binary object, which we cannot change in any way, so it's frustrating because we can't do anything about basically any bugs. Upstream distributes their code in a weird, annoying package format. It's also very complicated, full of random upstream libraries for providing various interfaces to the GPU to do computing, and it conflicts with and replaces various X bits like the GL library. And on top of that, it comes in four different variants, all of which need to be separately packaged, plus a bunch of supporting packages and libraries (some non-free and some free). Oh, and it builds a kernel module. And we historically provided pre-built kernel modules and meta-packages. And the packaging infrastructure hadn't been overhauled in quite some time, so it wasn't using current packaging techniques.

Did I mention the RC bugs and the nearly 200 open bugs on just the main non-legacy package (now much lower thanks to Andreas's hard work).

We're slowly making progress. nvidia-graphics-drivers migrated to testing for the first time since around the lenny release and now supports DKMS, and Andreas has massively modernized the packaging. We also have just about finished the transition to using the free libvdpao library rather than the one included with the NVIDIA packages.

But given that background, you might understand why one might find blog posts like this one (about a bug that was first reported for KDE just one week ago!) just a little demotivating. (The problem had been previously observed with GDM, but it appeared to be fixed somehow in GDM 3.)

I'm sure there are better ways that I could have communicated the bug status, and I probably stressed a bit more than I need to the point that the module is completely opaque and non-free and there isn't much that we can do to change its behavior. But reading negative comments about one's work on Planet Debian is really kind of frustrating, particularly when that work is on something that it's hard to get Debian to care about and that's kind of thankless to start with.

I'm not trolling for praise here; I have a thick skin. But this does seem like a good opportunity for a reminder that this is a volunteer project, some packages are kind of annoying to maintain, and things take time. If you don't agree with a maintainer's determination of whether or not something is RC (I still don't think this bug is RC), one can certainly have that conversation. But unless the maintainer marks the bug wontfix, please don't jump to the conclusion that no one cares about trying to find a resolution. And one week is a rather short time period to arrive at that conclusion, even if the maintainer is fairly negative about the bug. Sometimes that just means that you caught them on a bad day.

For the record, I'm currently pondering asking the people with this bug to try adding nvidia to /etc/modules and see if forcing the module load earlier works around this problem. I think what's happening is that the module is doing some sort of prolonged initialization, and it just needs more lead time before it's expected to respond to the X server.