Thomas Rast <trast@xxxxxxxxxxx> writes: > Nevertheless, AFAIK it has never been used for "real work", so you may > want to look into why that happened, and do something different. Hrm, I totally forgot about that site while we were discussing this yesterday. We only see three "issues" there, and that shows nobody bothered to register issues, and it is very understandable. People who read the list know that all communication that is important to Git happen here, and it will be an additional burden for reporters if they have to go there (be it Jan's site, Andrew's one, or the issue system at GitHub for that matter) and put what you already have posted. People who do not read the list had no chance knowing about Jan's site to begin with, given that even I didn't immediately remember. Also more importantly, the issues posted here are picked up and acted on reasonably quickly---it often is more than "reasonably" quickly and I often find myself looking at a new initial report, analysis of the problem and a tested patch in a single thread, when I check my mailbox the morning. Such an issue won't hit the tracker, and neither the initial reporter nor the developers who responded should not do a lot of extra work to get the thread in a "bug tracker" system. Something based on the idea mentioned in Ævar's message (downstream in this thread) to seamlessly integrate with the e-mail traffic might have a chance to succeed. I also think the integration must be two-way for it to be useful. A summary of "new issues untouched for N weeks" and another "older issues unclosed for N weeks" periodically sent here, or something. Perhaps collecting messages based on a handful of simple heuristics like "A message mentioned the keyword 'bug', but no In-Reply-To for it from any list regulars came in two weeks" might be a good place to start. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html