On Wed, Sep 14, 2016 at 11:21:44AM -0400, Stephen John Smoogen wrote: > On 14 September 2016 at 10:44, Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote> > I disagree in general; when the bug volume exceeds a certain amount > > bugzilla basically becomes useless. However, it would be really nice if > > _someone_ looked at RH bugzilla for those packages and did something > > with them. I disagree: _any_ bugtracker becomes less useful, or more correctly, bugtracking in general becomes harder and more draining when the bug count becomes so high that you cannot remember all the open bugs. Bugzilla might not be the least cumbersome of trackers, but the real problem is having too many bugs and too little maintainers. > > We used to have "bugzappers". What we really need is someone to do > > triage and to forward bugs on to upstream when appropriate. This > > obviously requires volunteers. > > > > I think this is an excellent job for someone who wants to help out. > > Does Gnome have documentation on performing bug triage like our kernel > > team does? https://fedoraproject.org/wiki/KernelBugTriage > > > > All volunteers would really need is accounts at the upstream trackers, > > the will to search for duplicate bugs there, and some basic knowledge of > > when to ask for more information and how to properly select components > > upstream. I would imagine that a large number of the bugs that are > > filed are duplicates of existing bugs anyway. > > > > Note that I sadly don't have any free time to actually help with this. > > I've tried to do kernel bug triage, and it's very, very difficult and > > time consuming. But that's the kernel; I would hope that just sorting > > out Gnome bugs wouldn't be quite so bad. > > > > It is just as bad for pretty much the same reasons: > 1) Do you have access to that system. > 2) Is the problem in the app or in X or in the kernel or the hardware. > 3) If it is in the hardware is it a monitor/video card/motherboard issue > 4) If you think it is in the kernel go to kernel triage > 5) If you thinking it is in X follow the kernel triage but use s/kernel/X/ > 6) If it is in the app can you even figure out what configuration caused it? > 7) Is the bug really in the app or in some side app which it talks to? I think you're painting an overly bleak picture: for most backtraces somebody who knows the code well can tell what's wrong. I don't know the gnome codebase at all, but I look a lot at systemd backtraces, and there's very few "unresolvable" ones for which we cannot determine the reason. I don't think gnome would be different here. Taking the list that Jakub Filak posted [1] as an example. The second most frequent trace on that list is an assertion failure in gdk_event_source_check [2], and the first is a segmentation fault in thumbnail generation [3]. I doesn't sound like hardware issues. [1] https://retrace.fedoraproject.org/faf/problems/?opsysreleases=122&opsysreleases=123&associate=51 [2] https://retrace.fedoraproject.org/faf/problems/bthash/?bth=2dc809f76a6e964ae97bca1d5ab19c6e44a52e37&bth=3d180ca127e69c831065f0528626b2dfb4bb2a97&bth=5c45986c061edd916962c68b83caa7540ac07c82&bth=722d98e99bc0a4898af9622f92ca103d0bf2bc38&bth=94e4a7c759fa0e9888ec9abe4255a4e1a6026c86&bth=9786755e1049db543438f825966598ebd2cc1647&bth=e6ca80c9f6ea0704148d59c89228af59df54ae32 [3] https://bugzilla.redhat.com/attachment.cgi?id=1187004 #0 cmsGetColorSpace (hProfile=hProfile@entry=0x0) at cmsio0.c:934 Icc = 0x0 Looks like a standard NULL point crash. > On the other hand, we have this conversation every (or every other) > mid release cycle... so maybe we should just do the play one more > time. Some drama about how Gnome sucks, gets special treatment, or > isn't as special as systemd, is always put upon.. Dunno, to me both systemd and gnome "suffer" the problem of too many users and not enough maintainers. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
