On 2017-12-26, <bytevolc...@safe-mail.net> <bytevolc...@safe-mail.net> wrote: > If I were to set such a thing up, I wouldn't even bother pulling stuff > from tech@ and bugs@ at all. Too much work, no real benefit.
"too much work". I think you misunderstand bug trackers. They aren't some magic thing that automatically turns a submission into a usable bug report. Whether reports are coming from list posts or ticket submissions, the triage and information gathering still needs to be done. > The project seems to do well even without one, and maybe the devs are > satisfied with bugs@ and tech@ already. What issues/problems in > workflow will a bug tracker resolve that cannot be covered by bugs@ and > tech@ lists? bugs/tech@ are better than the sort of tracker you'll get from someone who thinks it's enough to just set it up, let people post bugs to it, and lets devs deal with the rest. But they definitely have problems. - Forgotten unfixed bugs. - Forgotten *fixed* bugs (i.e. where the fix hasn't been committed). - Crappy bug reports where developers have to drag the information out of the reporter and it gets fragmented across a dozen posts, some on list, some in private mail. In short: if someone wants to do the work to fix this, that's great and I'm trying to make sure anyone thinking about this has an idea of the work involved. It would be a useful way someone with good general knowledge of the OS but maybe not so much in the way of coding skills could help. But at the same I'm trying to make sure people know that simply setting up ticketing software then walking away is not going to be helpful.
