As for syslog files, it is usually best to include only an excerpt, not the entire log. There is a convenience function in the apport.hookutils library which makes this easy.

We should definitely eliminate “harmless” error messages which lead users to think there is a problem. These should be filed as bugs, and fixed. bug 58386 is an example of where we’ve fixed such a problem.

Adding facilities to tighten bug time resolution equals improving a lot ubuntu-linux quality.

Keep up.

When googling about an error/warning we sometime/often be scared by an useless warning (recently i’ve searched about “can’t find devive.map” when booting: the devs discussions about that are: error generated by an old mechanism no more used with today’s kernels, but the warning is still there & the first thread is not recent: time to decide who have to do the modifications). That kind of error need to be identified (and the others too) and declared as no-serious/medium/dangerous or hided when useless.

( Some brain storming for internal design )

http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/revision/1480

to help with the network-related bugs.

Good post; As you says, a lot of bugs are filed; for me that means that the community is growing up, most of users are able to report bugs, the “apport” script is the best usefull way to let devs knows about troubles, if there are others let we know of course.

How to do better:
- promote “apport” when a crash / log warning appear, with the good syntax to be used & the top best option (recently discovered “apport-collect” for example).
- review “apport” to be more powerfull (dependencies / suggested packages: apport-retrace, …) & always up to dated.
- So apport is a good tool but don’t ask informations about it: have you tried “man apport” or “help apport” ?
- lot of bugs are reported as kernel’s ones but they are not: video driver, script, main libs (libc / python, …)
- Ubuntu use & introduce lot of experimental packages which produce a wide range of troubles & bugs. If most of them are quickly resolved by updates, some others depends on external projects ( mozilla, gnome, …) & sometimes take age to become rc or final release. Compared to Sidux, Ubuntu stay bugged longer. So, merging packages have to be made shortly.
- new linux users are often lost because they are not techies, don’t know how & where to report bugs or are disapointed with their bug report if it take age to be resolved: how many bugs are just declared “invalid” because of missing informations without indications about them to help the bug author to give them back ? So, Ubuntu users are not only techies and if devs want to divide the bugs number, they have to pay attention about the bug calendar ( oldy buggy package producing bug on other package), the “5 bugs a day” was a good idea.
- i think that a choice have to be made about apt-get / aptitude: often some warnings, freezes, crashes appear because of bad updates / upgrades: most of them can be resolved by removing/purging & reinstalling packages. So, “apt-get” or/and “aptitude” does not take care enough about removing/purging the settings/libs/links/… left behind the updated/upgraded packages: can find the same package installed with different releases at the same time even if the older one is no more needed by an other package. Only need a strong solution: is apt-get or aptitude the future ?
- neither “find orphans” (gtkorphan) don’t find multiple release of the same package nor janitor.
- new choices have been made about hal/udev but lot of configs are not up to dated.

To resume i would say that it’s time to clean the sweat home !!!