Agreed, partially, with both of you. It may be possible to automatically filter some of the chaff (user errors and support requests in disguise) in one large batch so to pressed the DB but forwarding mailing list touches to the bug tracker would make things ugly fast.
What would be involved to pull the current state of bugs@ and tech@? > On Dec 25, 2017, at 12:21, Stuart Henderson <s...@spacehopper.org> wrote: > >> On 2017-12-23, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> wrote: >>> On 23/12/17 12:24, Stuart Henderson wrote: >>> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to >>> triage, identify what is a bug, follow up with the reporter to make >>> sure the report is accurate and has enough information to be useful. >>> Same whatever the entry point is. If reporters can add bugs to it >>> directly, they need to go into a triage queue and *not* appear in the >>> main system until that's done. >>> >>> The idea of a bug tracking system is to spread the work and help >>> people remember things. It should *reduce* work done by devs because >>> they no longer have to drag even the most basic information out >>> of a reporter and figure out whether it's a bug or user error >>> or a support request in disguise. >>> >>> If it means *extra* work for devs, it's not going to work. >>> >>> >> >> I still don't agree with you about maintaining both @tech/@bugs in >> correlation with a web interface (bugtracking). >> Not a gain, just extra trouble. > > Probably not long term, but looking at existing unfixed bug reports on > lists would be a good way to seed the database. And information spread > across multiple mails can be synthesized into a coherent report, > hopefully going some way to showing others what a proper bug > submission should actually look like. > >> What happens in other places is that if a mail comes that looks like a >> possible ticket (not resolvable by mail), someone replies and says >> "please open bug report in https://..."; >> so we can track it. >> However you 're right with the last paragraph above and it's something I >> haven't thought before. >> More people might get involved and eventually this might get some work >> out of the devs. > >
