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:
1. If a submission fails, please do not clear any fields, in
particular "Module" and "Platform".
Presumably fixed (issue267).
2. Please add "x86_64" to the list of platforms.
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?
3. If it is not the case that Linux is assumed, please add
the list of platforms.
Same comment as 2.
4. It would be nice if there were a "Next" button (like in
to go to the next issue in the current list. (I happen to be working
off the Open issues list, so "Show Open" works for me.)
What next issue? Does it matter?
5. Shouldn't every issue have a status of at least
"New"? If so,
please make it the default when submitting or modifying an existing
issue which does not have a status set.
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
How about "Unseen" or "Needs triage" for the default (ie, change the
name of "-- No selection --"), and change the name of "New" to
6. If an issue is the result of the interaction between two modules,
then the "Module" field will not capture essential information since
only one module can be specified. The "Module" field should be a
New issue 476.
That's probably easy enough to do for new issues. I'm not sure if it
can be fixed retroactively.
7. There is no way to save the current issue list or to re-load a
previously created issue list.
Why would you want to do that instead of running a saved search?
8. Comment text should be forcibly wrapped (or should be an option).
See Issue 150 for an example of an issue that's hard to read.
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.
9. "core code other" should be broken up[sic] into
"core code other"
and "core code lisp", with "core code other" covering lib-src and
lwlib and "core code lisp" covering (obviously) the core lisp code.
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.
10. "Make a copy" doesn't work and returns errors.
Verified, new issue 473. Looks to be deep in Roundup, though.
11. The Comment field seems to start up with a number of spaces
tabs. So, when clicking anywhere except at the very beginning, the
cursor is misplaced. The spaces & tabs should be removed.
I'm aware of that, but I haven't found where it's coming from.
New issue 479.
12. The automated transition to "deferred" after one month
inactivity doesn't seem to work. I've opened 8 month old issues that
are still "chatting".
Verified, new issue 480. Something's misconfigured, probably the
tracker is looking for a field I've changed or moved.
13. When I forgot to fill in "Module", "Submit
something like "Required issue property platform not supplied." This
should refer to "module" not "platform". (But, next time it worked,
maybe I'm hallucinating.)
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".
14. There should be an "N/A" in the module list, for use
issues is not a bug. Same comment for "Type".
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.
15. The elements in the platform list seem to be missing some
Linux, Solaris, lwlib, motif, SPARC, but nt is mentioned even though
mswindows is in the list. And what is "stream"?
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
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