Vanessa, since you ask, those are four more examples of illogical reasoning. The first is a straw man: "no we won't do that and we won't tell you about it". Nobody has suggested that. Everyone agrees that the man page does not match reality. As unknown and Holger have pointed out, notify-send can't be *sure* that the the server will ignore the timeout -- mate-notification-daemon implements it, at least -- but both Notify OSD and Gnome Shell do ignore it, so it is ignored for most users. That is a bug, but it is not a bug in Notify OSD, it is a bug in the man page. It's roughly the equivalent of a Web reference describing HTML's <blink> element without mentioning that the browsers used by most people now ignore it.
The second is assuming the question: "we have proven it with this thread alone". As I said earlier, the cases described in this report are cases for which *any* asynchronous notification system wouldn't work reliably -- whether they had developer-configurable timeouts or not. The notification your app triggered might be queued behind a dozen from other apps, and therefore not appear until a full minute after you wanted it to.
The third is an invalid premise: "Linux is community based, anyone can contribute, the features that people want get in." Features people want are often rejected from Linux. For example, there is no user-switchable option to choose BFS or any other process scheduler, because to quote Linus Torvalds, such an option would be "really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of". The same is true for most other components of Ubuntu, including the notification server; their designers often say no to things. But just as with the kernel, you are welcome to install or compile your own.
And the fourth is a sunk cost fallacy: "We've wasted so many days and weeks on this topic, it needs to be addressed". The word count in this bug report is not evidence of anything except people's awe-inspiring willingness to post comments instead of fixing a man page.
Finally, since you asked, Ubuntu 12.04 experiences a crash or similar error, on average, once every 25 days, 13.10 once every 14 days, and Trusty currently once every 11 days. The equivalent figures for Windows are not public.
Vanessa, since you ask, those are four more examples of illogical reasoning. The first is a straw man: "no we won't do that and we won't tell you about it". Nobody has suggested that. Everyone agrees that the man page does not match reality. As unknown and Holger have pointed out, notify-send can't be *sure* that the the server will ignore the timeout -- mate-notificati on-daemon implements it, at least -- but both Notify OSD and Gnome Shell do ignore it, so it is ignored for most users. That is a bug, but it is not a bug in Notify OSD, it is a bug in the man page. It's roughly the equivalent of a Web reference describing HTML's <blink> element without mentioning that the browsers used by most people now ignore it.
The second is assuming the question: "we have proven it with this thread alone". As I said earlier, the cases described in this report are cases for which *any* asynchronous notification system wouldn't work reliably -- whether they had developer- configurable timeouts or not. The notification your app triggered might be queued behind a dozen from other apps, and therefore not appear until a full minute after you wanted it to.
The third is an invalid premise: "Linux is community based, anyone can contribute, the features that people want get in." Features people want are often rejected from Linux. For example, there is no user-switchable option to choose BFS or any other process scheduler, because to quote Linus Torvalds, such an option would be "really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of". The same is true for most other components of Ubuntu, including the notification server; their designers often say no to things. But just as with the kernel, you are welcome to install or compile your own.
And the fourth is a sunk cost fallacy: "We've wasted so many days and weeks on this topic, it needs to be addressed". The word count in this bug report is not evidence of anything except people's awe-inspiring willingness to post comments instead of fixing a man page.
Finally, since you asked, Ubuntu 12.04 experiences a crash or similar error, on average, once every 25 days, 13.10 once every 14 days, and Trusty currently once every 11 days. The equivalent figures for Windows are not public.