Willy, Am 08.01.19 um 18:30 schrieb Willy Tarreau: > I totally agree. This is the tool I'm missing the most currently. I'm > not aware of a *good* and manageable issue tracker. Having a status for > a bug per branch most likely eliminates most of them...
I'm not sure this is required. The bugfixes naturally land in the current development repository and have the affected branches in their commit message. They naturally "trickle down" to the maintained branches. So if the issue is marked as fixed the fix will *eventually* appear in the stable branch of the reporter. The "first responder" will try to reproduce the issue both in the current dev version (to see if appears in bleeding edge) as well as the most recent version of the branch the reporter uses (in case it was accidentally fixed during a refactor). If possible the first responder creates a reg-test showing the issue. > I'm really not convinced it would change anything. We've put prominently > on the previous repo an indication that it was not the official project > and that issues / PRs were not accepted, despite this your automatic bot > was needed to close them. My goal is contributors efficiency. Several of > us are on the critical path and every minute they waste slows someone > else down. So if it becomes more annoying for everyone to create a new > issue just for the purpose of discouraging wanderers from trying to > create them, it will only have a globally negative effect. In my experience non-issues (a.k.a. RTFM) are usually easy to detect when reading through the explanation. >> >> 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. > > I do have strong doubts but I'm open to trying :-) I have to agree with Lukas here. Proper triaging is key here. And this is no different to email. You have to read email to decide what to do. And you have to read the issue to decide what to do. Labels in the issue tracker are like folders in your mailbox and the issue tracker itself is like a public mailbox. >> 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. > > Oh yes! I just want to be sure we don't burn you out! This is also why > I'm open to trying what those doing the work propose. If I'm imposing > a painful or inefficient process for those doing the work, it will not > work either. I'd throw my hat into the ring as well. I maintain a few Open Source projects myself (though not of the size and importance of haproxy) and actually use the GitHub issue tracker. >> 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. I would suggest using GitHub's issue tracker as well. It works fairly well in my experience. > I'd say that we managed to close the issues there when we discovered > them. It took a huge amount of efforts, sure, but eventually it was > done. So if we figure later that it was a wrong choice, we know it can > be done again. In this regard I think it's the lowest cost to *try*. > > However I'd like that we spend some time thinking about what can be > done to properly route the bugs to the various branches. Bugs in dev > are useless, we want them to be fixed in stable branches. So we have See the very top of my email. > Thanks a lot for these links, they are very informative. This utility > doesn't "yet" support cross-branches, but it's said that bugseverywhere > does. But bugseverywhere claims that its value is in keeping a hard > relation between bug's state and the fix in the tree, which precisely > is the wrong way to do it for me : I strongly prefer that the bug tracker > is never fully up to date regarding the resolved status for a branch than > having it believe the branch is fixed because it doesn't know that this > branch requires an extra patch. An apparently unresolved bug will be > noticed by the next person trying to resolve it. It's how it really > works with most developers and bug trackers in real life. I had too > quick a look at the other ones for now. Please don't opt for some obscure system. The biggest value of a public issue tracker to me is that people are actually are able to research whether their issue is already known / a duplicate and possible workarounds. The mail archive is not really accessible. > With that said at the moment we don't have anything and the situation is > not better than having a suboptimal tool. I agree. Best regards Tim Düsterhus
