# from Aristotle Pagaltzis # on Friday 05 September 2008 06:07: >> UNIVERSAL::isa and UNIVERSAL::can are examples of applying the >> design principle of Report Bugs Where They Are, Not Where They >> Appear. > >How do you propose doing that in the general case? I am certainly >interested in what technology you have invented so that computer >programs can automatically debug themselves and detect the real >source of any problems.
I too am interested in this technology and would like to subscribe to its rss feed. But to the extent that we must solve technology problems with people, I'm interested in using technology to leverage the efforts of those people. In the case of e.g. the CPAN.pm bug/issue with -j or tar, we have identified these issues at the cost of perhaps dozens of spurious FAIL reports to various authors. If it is possible to track down all of these reports and "cross them out", this would eliminate confusion and possibly duplicated effort -- and would make the annoyance of the false FAIL less of a "take one for the team" (because uh, "take what where?") Now, this "cross them out" might mean deletion, but possibly just simply mumble~strikethrough with linking to the resultant CPAN.pm RT ticket or etc. (because "Hey, RSS said FAIL. *click* um... where did it go?") It also keeps the author from looking at this in e.g. 6 months and thinking "FAIL? ... oh, right. I forgot about that silly thing, well can't do anything about that." http://testers.cpan.org/show/Error.html So, whether a 2.0 design consideration or whatever, please help me get the things I don't have to remember out of my brain and into the computer. And maybe I'll even be able to help keep other authors from scratching their head wondering what happened. And yes, it will take some people some effort. But everyone else will appreciate it and if I put in the effort myself I even get my 100% greens back on my own page, which is a nice motivator because I can do something about the evil fake stupid wrong reds besides complain. :-D Is there a machine/configuration identifier of some sort and/or other ways to characterize a "report source" such that once the cause of a false report is identified every report caused by that same issue could be automatically crossed off? And now, feature creep: optional notifications of "please disregard these reports: ... " for affected authors who have just started ambitiously scratching their heads at the time the issue is identified. ;-) Thanks, Eric -- "It is a mistake to allow any mechanical object to realize that you are in a hurry." --Ralph's Observation --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
