Ulrich Drepper's personality

The eglibc switch has it's roots in the openssl patch epic fail. Since then, it was deemed that patching upstream is generally bad. Changes to code should be done with co-operation from upstream. Some developers (such as the glibc maintainer) raised the valid question of what do when upstream refuses to accept patches? (Too lazy to search for the debian-devel specific discussion).

The upstream certainly has all the rights to put up whatever QA and codestyle requirements they want. The maintainer of the package has the duty to fulfill such requirements and correct any issues in the patch noted by upstream. The end result is better for everyone - debian gets a better fix, and all the other users get the fix too when upstream releases new version.

But what do when upstream plainly refuses to accept a patch? Or tells you to "Go away, stop wasting everyones time"?

One option in such cases is to start maintaining a explicit fork (or spork, as mentioned here). It is more honest for endusers than maintaining a ever-growing stack of patches hidden in a distribution source package. And if others have the same problem(s) with upstream, the spork allows sharing the maintenance burden.

Other options could be switching the maintainer (it is always the upstream that has co-operation problems...) or dropping the package all together (if there are better alternatives).