Stephen> There's discussion about a BTS for GNU Emacs going on on Stephen> emacs-devel(a)gnu.org (ifyou're not subscribed, I think you can Stephen> access the archives from Savannah?). Yes you can. Is it the thread "Bug Database?" you are referring to? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Yes. I guess since this subject has been raised it is time to debate the issue again ;-) Anyway, seriously, what I think is missing is an easy way to find what bugs or issues there are. If it is easy to get an overview of the bugs they might get fixed because it is then possible to pick a bug and fix it. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> However, if we make any serious effort at entering Stephen> outstanding reports, say from the last year, I'll bet we can Stephen> easily get a couple hundred issues. How about the strategy of just entering new bugs and old bugs that the bug reporter feels like should go into to bug tracker. This would mean having bugs reported and handled in two places but it wouldn't burden this try to start with a lot of administrative work. There will probably be some of that anyway. Stephen> We are going to need workers to enter the issues, classify Stephen> and prioritize them, identify duplicates, link issues to Stephen> relevant mailing list threads, and close fixed, bogus, or Stephen> unfixable issues. These are tasks that need to be done if you handle bugs whatever system, manual or automated, is in use!? Stephen> Would anybody like to do that? People who volunteer to do Stephen> that work get two votes on the choice of tracker. :-) To me that seems essential for every developer to care about. I'm sure though you got a point in that there needs to be one or a few people who feels a bit more for maintaining the tracker. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

stephen> Sure. But the current way of "handling" them is "each hacker stephen> keeps a private list, typically in his head". That's very stephen> little work. :-) Which probably suffer from slightly more bitrot than your typical bug tracking system. ;-) Skip _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Uh, this is a volunteer project creating free software. There's nothing that *needs* to be done, because anybody who wants it done always can just do it (if necessary, in a fork). You suggest (by writing "ought") that this is somehow an obligation of the developers. It is not. For XEmacs, that was settled in long and acrimonious discussion in which I lost a lot of goodwill from other developers, as well as the argument. Basically, developers in this project have no obligation to do anything except produce good code according to their own standards, and to not damage the results of others' work. All other "obligations" are self-imposed. I will say that such volunteers are rewarded with respect and other "good and valuable consideration" in this project in my experience. And the core developers do pitch in and help greatly when somebody takes a valuable initiative. The project does (mostly :-/) "work" under this minimalist "social contract." But often, as with a bug tracker, that initiative has be backed up with a long-term work commitment. I'm willing to shoulder some of the work, Mike is too, but up to now the offers that we've had are hosting and site admin---not bug tracking. I'm sorry, the host and the software help, but alone they are low value-added. This project has plenty of access to hosts, and several core developers are able and willing to install and admin software on them. It's the bug tracking *work*, today, tomorrow, and the next day, that is the sticking point. In this project, under the current "social contract", that is not an obligation of the developers. With Mike pushing it, we now have a critical mass of core support for an ITS and it will happen. But without new volunteers we can't do it *well*. On a day-to-day basis, we need people to assign bugs to developers, to classify them so users can search them, and critically evaluate the classifications and admin interface so that we can improve them. (One reason I'm pushing Roundup is that I know that its architecture can in principle support a lot of improvement and innovation in those areas without a major rewrite, and I know I can personally do the work (if nobody beats me to it ;-).) Even an hour a week of assignment and classification work from two or three people would make a big difference in the quality of the database. Regards, Steve (By the way, I believe that most of the Review Board would sign on to much of what I wrote above, although they might prefer to word it differently. But I do not claim that my views are representive of the Review Board here.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Ah, OK. No problem, I've just been hanging out in low-level LUGs with lots of escapees from proprietary software recently. Note to self: consciously remember that on the XEmacs lists people are adults until proven otherwise in triplicate. :-) It will ... but it has to be used by the developers regularly or it will be the wrong kind of attention (ie, users posting bugs and patches that end up as fancy floor tiling). Yes and no. Anything (that people actually use nowadays) will work with sufficient effort. I want that effort to result in immediate improvements to the XEmacs experience wherever possible, without having to fight with the tracker/browser/backend db. There are too many BTSes that I don't use nearly as much as I should because the effort to search is too large, the page organization sucks, or the developers never respond anyway, or some combination of those and other factors. *Some* of those problems can be solved by better ITS. For example, try searching on keywords on most ITS's. Can you get a list of indexed keywords? Hah! Can you create a "thesaurus" (ie, links between keywords so that "GPF" or "blue screen" gets you all the crash reports? bonus points for those keywords listing Windows reports at the top!)? Hah! Hah! Can users "suggest" keywords and thesaurus entries? Hah! Hah! Hah! Suppose you realize that you just saw a bug report that is not really the same (otherwise you'd comment there) but might be related. You go search that bug, and then you try to return to your report but it gets cleared by some browsers. On some browsers, C-e is an editing command (at least in the text box); on others, it causes the current page to be refreshed :-(. OK, that last is a PEBKAC, but it's caused me to go to bed at 1am and never redo the report more than once. There are ways to make that kind of thing less likely. Heck, while we're at it, we should just dump the whole FAQ into the ITS. Just because it's a FAQ doesn't mean it isn't an "issue" for the user! But we probably don't want those to look like open or even reopenable issues. Further suggestions welcome. I'm sure it will, once things get going. I just wanted to share my opinion that the critical mass for making a big dent in the mess is quite small. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta