Please...(again)...

This is both hilarious and quite accurate. It is only missing the last two stages.

First the Developer becomes slightly bored and not interested in re-implementing all the useful workarounds that the original piece of software featured in order to cope with the real world. Because it is so much better to fix the real world instead!

And then the final stage where the Developer becomes really bored, realizing that he has solved all the interesting problems. He then jumps on his white horse and rides to new pastures, to other crucially important pieces to entirely re-design and re-implement. It is very urgent to free users from these other broken pieces since they have been suffering from them since a few decades now! Average, boring people like you and me will be good enough for the mundane task of maintaining the current project.

Seriously, though, I can understand Lennart's point of view here. With pulseaudio and systemd, he has created code that is better than what came before it. But the problem with straightening out the crooked things is that it causes a lot of short-term pain.

What I've found in the past is that when you make a big change to something, you spend more time handling "transition issues" than you do actually architecting the new solution. Usually you have provide compatibility and "legacy" modes, do extensive testing, and fix a lot of problems that have absolutely nothing to do with anything you've written, but which just happen to crop up when your new solution is place.

As you can probably guess, handling transition issues is *not* the fun part. It's the boring but difficult part. There is often a temptation to skip this part-- just like there is a temptation to put off writing good documentation. But you absolutely must not do this, or else you will make a lot of enemies.

The worst part is that if something breaks, you will be the bad guy, no matter whose fault the problem actually is. It could be a bug in the python interpreter that is being exposed by your kernel change-- and you will get the blame. The only response is to be professional about it-- to offer compatibility modes or workarounds, and get to the root cause of the problem. At some point, this is just the fate of all engineers. You never think about the guy who built your highway onramp-- until something bad happens.

Lennart's flippant response about the "noauto" change suggests that he still has to learn how to really do this right. Hopefully he'll get the hang of it. And then we can finish building that hyperspace bypass. After all, the plans *have* been on display for 50 of your earth years.