Non-urgent Tracker blatherings

Summary: Issues 4, 7, and 14, I don't understand. Could you explain more? Issues 2, 3, and 15 I'm philosophically inclined to do nothing, but I could be persuaded. Issue 13 is a "works-for-me". The rest are genuine issues, see comments for details of how I propose to handle them, etc. Vladimir G. Ivanovic writes: Presumably fixed (issue267). New issue474. Also comments 3 and 15 in the same issue, since I see this as a philosophical issue, not just some random missing platforms. So, where do we stop, then? Should I put in the full list from config.guess? It's true that 64-bitness and endianness matter, I guess I could put those details in. On the other hand, is it worth asking users to make the fine distinction? Same comment as 2. What next issue? Does it matter? New issue 475. The logic is that I want something to search on for triage. Priority currently serves that function in the default "Show Open" search, but only for mailed issues. It defaults to "normal" for web-created issues. How about "Unseen" or "Needs triage" for the default (ie, change the name of "-- No selection --"), and change the name of "New" to "Classified"? New issue 476. That's probably easy enough to do for new issues. I'm not sure if it can be fixed retroactively. Why would you want to do that instead of running a saved search? New issue 477. Option maybe, default definitely not (error output is often easier to read with long-lines not wrapped). This probably won't get addressed very quickly unless people point me to several problem issues. New issue 478. "Core code other" was intended to refer to non 21.4 or 21.5 versions, such as 21.1 or the Carbon branch. I guess it could be broken up that way, but then version would have to be a separate field. I agree something should be done, but it's not clear to me that your suggestion is a good idea since Lisp differs a lot across 21.4 and 21.5, it matters which version for Lisp. So we need to address that. Verified, new issue 473. Looks to be deep in Roundup, though. I'm aware of that, but I haven't found where it's coming from. New issue 479. Verified, new issue 480. Something's misconfigured, probably the tracker is looking for a field I've changed or moved. I can't reproduce. It's possible that you accidentally cleared the platform property. When I did so deliberately, I got "Required issue properties module, platform not supplied". I don't understand. In general it still will apply to a particular module or component of XEmacs. If it doesn't, why is it being posted to the XEmacs tracker? I would prefer to make the list more complete. As for type, "discuss" is intended to be used as a catch-all; defect, feature, and patch capture the most common types of issues IMO, I'm not sure what "discuss" should be used for. The logic is that bugs in the C code generally are going to depend on CPU, OS, and the console type (or UI). "nt" is an OS, "mswindows" is a console type. "stream" is a console type (you can actually play M-x doctor or M-x dungeon with only stdin and stdout, no curses!) The precision of the list has to balance exclusion of irrelevant bugs in a search (so one would like to distinguish among Xt-based widget sets like Xaw, Motif, and Lucid), inclusion of relevant bugs in a search (if an Xt event loop bug manifests on Xaw, Motif, and Lucid, that's three instances of one bug and they should be collected in the same search) and user convenience in reporting and searching. I chose to break things down on the basis of the console type, which is approximately equivalent to the event loop, but not go to the depth of widget sets. If there are lots of bugs that differ across the Xt-based widget sets, and few that strike them all, I'll certainly revisit that decision, but without some facts, adding types increases complexity and the probability of missing relevant issues in a search, so I would resist it. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta