Re: Bug tracker: next steps

Wulf C. Krueger writes: Um, I wrote "worked with", not "reported to". It's not about "my" bugs, it's about the effectiveness of the whole system. Would you like to reread my post, and in the process discover that that's *my* point? I suspect that I'm above average for Gentoo users in terms of frequency of use of the ITS, and bug reporting in general, if not to Gentoo. I'm certainly way above average for XEmacs users. If I'm discouraged from reporting by what I see when looking up Gentoo packages' issue histories, how much more so will users be discouraged from reporting to an XEmacs ITS that behaves like xemacs-beta? If you would like to explain how XEmacs responsiveness is going change by installing a bug tracker, that would be of great interest. What I see on Gentoo as well as the others I mentioned is that it depends on the maintainer, not on the tracker. No? As for the need for an email interface, yes, I believe that's a genuine need, and I think *you* are being uninformed to deprecate it. We have infrastructure to support email reports that is not going to be reproduced for web reports for some time, and it's proven to help in resolving problems. In general I believe you are correct (again, that's one of my points), but "nobody" is unfair to Aidan Kehoe, who has done exactly that on (at least) one patch recently, and to Steve Youngs who actually fixed (at least) one of the issues on jwz's wish list, which is from the last millennium. There are also a number of things that have been hanging fire for years now (GTK, for one) but I don't know if that should count. Yes, I do, because they send us URLs to the archives where they reported the problem or sent a patch years ago. Er, those bug trackers are open to the public. It's easy enough to find plenty of examples that XEmacs should not emulate. But really, it's not about bug trackers, it's about the difference between active maintainers who acknowledge responsibility for a well- defined project, and XEmacs's current crew with "areas of interest" they're reasonably good about, but few well-defined modules so that we can automatically direct "pings" to appropriate places, and vast tracts of unclaimed code. All of the projects I've mentioned (except maybe MacPorts) have generally good reputations, but trackers for modules without active maintainers still end up being black holes. Do you deny that, even for Gentoo? Now, the three posts in the thread preceding mine all disclaimed, at least implicitly, responsibility for making sure that bugs get handled at least with a WONTFIX and apology. The point here is to find a way to do that given our very limited resources, or admit that we're not going to do so. If not, well, enough XEmacs hackers think it will make their work easier that an ITS is worth doing. But I don't want it advertised as a major breakthrough in responsiveness, especially not to people like you and Hans and Mike Fabian, if nothing major is going to change. So, back to the thread. Is a tracker going to help us to cover more of the bug reports in a timely, useful way? If so, how, and what else do we need to do to make that work? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta