1. 33

  2. 6

    Debian certainly has some serious NIH optics (in my eyes anyway).

    1. 2

      Indeed. This is an advantage of shipping packages as closely to upstream as possible. Either upstream is active and fixes vulnerabilities or you drop the package. Also, if some package has a problem, there is a stronger incentive to work it out with upstream. And upstream is not badgered with distribution-specific bugs.

    2. 2

      Well, I’m not sure it is all that black and white. I haven’t done much searching but it doesn’t seem like Patrick actively worked on his fork being included as XChat’s replacement. Sure, he reported a bug in Fedora but it doesn’t seem like followed-up on it.

      Also, despite the fact that XChat isn’t being actively developed, the original author doesn’t want it to die and to give the domain name up - he renewed it.

      … Just sayin’.

      1. 1

        I still maintain that it’s not the responsibility of distro maintainers to write or modify patches. (This is a pretty unpopular position, I know.)

        About the only distro I know of that actually takes this philosophical position is Lunar, which doesn’t help my argument. But, every time Debian (or another distro, but usually Debian) oversteps its bounds and screws up a perfectly-good package with ill-considered patches, I get to point to that instead.

        Distro maintainers are not experts on the packages they approve – after all, there are many packages (many of them extremely complex) and few maintainers. A package that requires patching by a distro maintainer in order to operate with other packages is broken, and the package maintainer should fix it (or it should be forked and fixed by someone who will maintain the fork). When distro maintainers create their own patches, it fragments actual bugfixes (which should be going directly upstream, not to a distro maintainer who won’t understand the implications), and creates potential bugs.