On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > That said, here's a potential pain point
Hi, please, do not forget of Bugzilla integration with backtraces. It can colorize them, it can show possible duplicates with score when the backtrace is opened in its own window, and it can even notify the reporter that the backtrace matches some other bugs and it offers the reporter to eventually join an existing bug, instead of filling a new bug report. Of course, an average user cannot decipher backtrace of random projects, thus it's fine he/she files a new bug report, but my main point for Bugzilla is that it knows what to do with inline backtraces. Does gitlab issue tracker know it too? Also, with respect of searching in Bugzilla, what some folks in this thread call complicated, I call powerful. Bugzilla is powerful in searching. The search UI can be complicated, that's why there is a Simple and Advanced search page, but it allows you do many good things. I've seen a screenshot of the gitlab issue tracker in an early stage of the wiki page [1], which I cannot find right now. It was full of colored tags, which effectively hid the main purpose, the information which had been meant to be shared. The page looked like a rainbow, not like a clean interface to share information between the reporter and the developer. One of the test issues [2] also looks somehow odd, but maybe if I would get use to it, then it might not be that bad as it looks like now. How many comments does it show? Four? One? Something in between? It looks like there are four of them, all grey thin font (hard to read), and wasting like 1/3 of my browser window height. Height is problem, not width, with wide screens. I didn't try how it looks like on a cell phone. The issue [3] also says: > Carlos Soriano @csoriano mentioned in issue #30668 (closed) 2 weeks ago Should that "mentioned" be "is marked as duplicate" instead? I can mention bugs between itself and I do it all the time (like "this is partly related to bug #1234", or even "can be duplicate of bug #1234", which used to do bug squad folks in the past too), but it doesn't mean they are duplicates, neither that I want to add some possibly misleading automated comment into the other bug report. I would mark them as a duplicate, or add them to Depends/Blocks, if I'd be sure. >From my point of view, it doesn't make much sense to have both Bugzilla and gitlab issue tracker running at the same time and let the product maintainers decide what is better for them. There should be some consistency. You cannot tell the reporter that the issue he/she filled belongs to other project, but that project issues are hosted elsewhere (even still under gnome.org domain). I understand this whole initiative to also make life easier for sysadmins, where maintaining two issue trackers doesn't sound like less work for them. Bye, Milan [1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/ [2] https://gitlab.gnome.org/GNOME/nautilus/issues/30668 [3] https://gitlab.gnome.org/GNOME/nautilus/issues/20958 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list