[CMake] CMake bug tracker discussion

[David Thompson]

> ...Controversial questions:
>
> - Should we eliminate the bug tracker entirely and just do all
> discussion and patches on the mailing list? ...
> - Or, alternatively, should we eliminate the bulk of mailing list
> traffic, and insist on issues in the bug tracker being the main
> conversational forum for the whole community?


Tradeoffs between push (mailing list) vs pull (bug tracker) seem like  
a very person-specific preference. Why enforce one or the other?

Also, I know it's slightly off-topic, but it seems like the  
alternatives you're offering are what people use frequently today as  
opposed to the way things should be (and what new tools are under  
development in those directions). For example I've been using ditz (a  
distributed bug tracker that uses git or hg to manage bugs) on a small  
project lately and enjoying it. It's not polished or maintained enough  
to warrant using it on a large project, but I mention it because I  
think it's an indication of how bug tracking might change over the  
next few years... It would be nice to have local bugs that I don't  
push to the community but which help me track my own progress.

I also happen to think that, besides becoming distributed, bug  
tracking systems will change in another way: they will more clearly  
differentiate between technical vs. narrative bug reports and handle  
both types. Currently, the strategies for handling bug reports from  
users is either (a) users can file bugs and many useless reports are  
filed or (b) users cannot file bugs and many problems are never  
brought to the attention of developers. I suspect (if it hasn't  
already happened) that a system for collecting **and mining**  
narrative reports (as told in the voice of the user, many stack traces  
with similar failures, etc.) will be developed that can tie to a  
technical issue tracker that is curated by developers (details of the  
problem and progress on it).

	My 1 to 3 cents,
	David