Nagy Gabor wrote:
An example: http://bugs.archlinux.org/task/5861 This is quite an old bug, and we are just waiting and waiting...
Sometimes packagers are slow, sometimes upstream is slow. This is not so surprising, the time of open source developers is always too limited :) Putting some pressure on upstream developers might help, especially when there is an very easy fix to a very annoying issue. And in this case, it was probably easy to build your own fixed package. So no big deal.
If the answer no, do packagers forward the bug to the official developer or the end-user should forward his discovered bug?
You should probably look yourself on the upstream bug tracker to know what is going on.
An other small example, which is much less important; but I think this belongs to the same "category", the reasoning is much more mysterious to me, since the "patch" clearly cannot break anything here: http://bugs.archlinux.org/task/10307 This was closed 4 minutes after opening, so I couldnot discuss it (I wanted to revert my last sentence there, this is not true now, I didn't want to lie). Evince developers like that option, and they don't want to change it. (But I don't agree with them here, of course). I simply cannot imagine any reason for "won't fix" (apart from "lazyness" :-P). I'm pretty sure that "implementing" it has _no drawback_, and at least 6 users (from the number of requests) would like it. Again, it is a marginal issue (I put my evince.desktop to NoUpgrade of pacman), but I would like to understand the reason of close.
Again, make sure that upstream is aware of this : that many users consider this was a bad move, and that many other distro have to patch it (specifying which exact distro and providing proof / links to source packages if possible).
But as you stated, this was also easy for you to fix this manually, so again, no big troubles here.
