Re: Proposal to deploy GitLab on

On Thu, 2017-05-18 at 12:17 +0200, Milan Crha wrote:
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?

The Traceparser is another (basically) unmaintained custom extension we
have in our Bugzilla, with some confusing bugs (e.g. bug 744491). 

GNOME Bugzilla does not receive gazillions of crasher bug reports
anymore (like after the 2.16 release, which was the reason to write
this extension if I remember correctly) and most distributions nowadays
ship their own tools (and own backends) for automatic crasher analysis.

The Traceparser is convenient but I would not strongly miss it if there
was nothing similar in GitLab. I'd say a regression we could live with?

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.

I do not know GitLab much but I'd expect functionality to set a color
when creating a label. So color rules could be established if wanted /
needed [4]. I'd call GitLab a way cleaner interface than Bugzilla. :)


[4] notorious Wikimedia example for project/tag/label coloring rules:

Andre Klapper  |  ak-47 gmx net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]