Hello everyone,
as per Tim's suggestion I'm restarting the discussion about the issue tracker, started in "haproxy 1.9 status update" (2018-05-25), Message-ID [email protected]: https://www.mail-archive.com/[email protected]/msg30139.html > It would be nice to show what's pending or being worked on, and > to sometimes add extra info regarding a given task. Yes, we are in need of an issue tracker, not only to handle open bugs, but even more so to handle feature/change requests that often need more time. Those do get lost on the mailing list, even when everyone already agreed it's needed. > The problem we've faced in the past with GitHub's issue tracker > is that it's impossible to restrict the creation of new issues to > participants. Given that haproxy is a complex component, the boundary > between human error, misunderstanding and bug is extremely thin. It is, but I don't like restricting the creation of new issues to participants. Issue templates need to be clear that the issue tracker is not a support forum. Triaging new issues will be needed anyway, and that also includes closing misdirected support request. To be clear: I think developers should not receive an email notifications for new or untriaged issues - only when specifically assigned to the issue or if they commented previously on it. Instead, maybe an automated weekly report or something like that (similar to what we have now for the stable-queue) could go out to the mailing list with a summary of the open issues, grouped by it's labels. > It resulted in the issue tracker being filled with wrong bugs, 100% of > which were in fact requests for help. It makes the utility totally > useless for development and bug fixing as it requires more time to > maintain in a clean state than it takes to put issues in a mailbox. What you are describing basically is a unmaintained issue tracker, which is of course useless. But keeping people from filing new issues is the wrong approach to this, imho. Proper templating, triaging and correct labeling of the issues is the difference between a useless and a useful issue tracker from my point of view. So I guess we ultimately have to decide between: - an issue tracker open to everyone, however requiring some volunteers to triage incoming bugs (and close invalid ones) - an issue tracker that is open to "previous participants", with the expectation to require less manpower for triage I'm in favor of the former, because I believe triage will be required for both and I don't think the amount of bogus issues will be unmanageable. I'd also volunteer to triage incoming issues - not that it's much different from what's currently done discourse anyway - as Tim already said. Regarding what tool to use, in the "open to everyone" case I'd opt for github simply because it has the lowest barrier of entry for everyone, as well as me being mildly familiar with it personally. Pre-existing github labels would have to be replaced by useful ones and a issue template would have to be created. > A limitation that isn't addressed by any of them is that an issue has > a single status and not one per maintenance branch. Some will say that > labels replace this but I'd say that this isn't true, it just vaguely > emulates this. Anyway if we don't have better we can go with this. I > often dream of the day someone pissed of by using prehistoric issue > trackers writes a modern one, just like when Linus created Git... There are some niche tools allowing a "distributed issue tracking system" within git, but they seem very fragmented, none of it gets a lot of traction and it would certainly over complicate things for a lot of people, including myself. See git-bug [1] and it's HN discussion [2], containing a log of other references [3-7]. Well I guess we would certainly not have many bogus issues reported on those systems ;) Regards, Lukas [1] https://github.com/MichaelMure/git-bug [2] https://news.ycombinator.com/item?id=17782121 [3] http://bugseverywhere.org/ [4] http://mrzv.org/software/artemis/ [5] https://github.com/sit-fyi/issue-tracking [6} https://github.com/dspinellis/git-issue [7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html
