Clemens> In contrast to the netiquette justified by the absence of Clemens> a bug tracking system, I like to push this thread as I Clemens> have not received any comments from core developers but Clemens> this bug definately needs the attention of some: Clemens> Message-ID: <20050924130559.GA26710(a)ghanima.endorphin.org&gt; Clemens> http://list-archive.xemacs.org/xemacs-beta/200509/msg00295.html On process stuff, Ben Wing is the expert. You can CC him at ben(a)xemacs.org. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Clemens> [...] justified by the absence of a bug tracking system, Clemens> [...] Mats> What is the status regarding a bug tracking system? I Mats> thought there was one on its way but then that was a long Mats> time ago. The BTS is me. At current rates of development, that's probably preferable to an automated system, because w/o it people query xemacs-beta and (eventually) I reply. If there were a BTS (a) they'd see that nobody is watching and go away, and (b) I'd feel no pressure to reply to queries because the BTS is on the job. As for an automated system, nobody has actually put any effort into doing anything about it. Bugzilla is unacceptable to me because it's still very email unfriendly, and apparently nobody feels very strongly about overriding my expressed preference. I've had a couple of offers to do something, but the people involved wanted guidance about what to use and would need substantial admin help from people with privileged access to our hosts, anyway. Anyway, a BTS is currently irrelevant. The core developers are either responding to bug reports on their areas or they aren't; there's no commitment to fixing bugs in general. In particular, I've forwarded all of Clemens's bug reports to Ben, and heard nothing back yet. So they're not going anywhere fast, and a BTS wouldn't speed it up. I believe this will change in the near future, as several dormant developers seem to be reactivating. But that's the current status. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Stephen J. Turnbull wrote: That is fine except that I miss an overview of what bugs there are. There ought to be small bugs as well as the big core developer stuff!? What are the requirements? There are less advanced systems than Bugzilla. Yours -- %% Mats

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: An important feature that Roundup lacks is flagging of duplicates. It also lacks resolution status -- when you close a bug, you cannot additionally specify the manner of its closing, like you can with bugzilla (RESOLVED, DUPLICATE, NOTABUG, etc.)

st> Here are *my* desiderata. This does not represent a consensus st> of the board. st> (1) It needs to accept submissions, additions, and st> status-changing commands by email. st> (2) Ditto for the web interface. st> (3) It needs to have a nice web presentation. (they all do, st> so that's not a problem, but there are better and worse an st> that's a consideration. st> (4) It needs to ping watchers on (a) new submissions to the st> issue or st> (b) status changes (at the watcher's option). st> (5) It needs to have ways of customizing the presentation, st> adding new types of issues, merging and splitting issues, st> etc. st> (6) It should be hackable by me and/or somebody with a long st> reliable association with the XEmacs project. st> (7) It needs to have a certain level of security. debbugs (2.4.1) The bug tracking system based on the active Debian BTS <http://packages.debian.org/unstable/misc/debbugs> Certainly has 1-4b. The remaining seem somewhat subjective. :) Start looking at <http://www.debian.org/Bugs/>;. There is (X)Emacs assisted bug reporting (debian.el). Two questions come to mind for which I have no answers at hand: can the Debian BTS notion of packages be easily adapted to XEmacs packages and how hard would it be to rip out unwanted Debianisms? A lot might be gained from the tried and true developer disciplines that are supported. jam

Mats> A web based system where just a few people, the core Mats> developers, can enter and manage issues I doubt I'll use it unless it works by email. Experience says nobody else will, either. We had one 1997-2000, JitterBug, not bad for pre-Bugzilla. It collected bugs, the bugs collected dust. AFAIK most of the developers were unaware of its existence. (Actually, that was the second try: there was an abortive attempt to use GNATS pre-1997.) Mats> but many, the rest of us, can read about them would be a big Mats> improvement (and probably easy to set up to.) Easy to set up, sure. The hard part is getting it to be part of the work flow. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Uwe Brauer <oub(a)mat.ucm.es&gt; writes: Debian's bug system is one of the worst bug trackers I have ever seen. Although its web interface has been somewhat improved, it's still miles behind just about anything else. It should be avoided like the plague.

Stephen J. Turnbull wrote: Stephen, I did write you a long response to the first message you sent me about this bug. did you not see it? it's attached again. as for clemens' idea of allowing throw out of redisplay, that's not a god idea because in some places the caller of redisplay() definitely does not want to have what they're doing interrupted. of course, they themselves should probably put the prison around redisplay, not have redisplay() itself do it. but anyway ... examples are in event-msw.c, in the windows procedure. as far as i know, longjmp[]ing out of a window procedure is *not* a good idea. {any windows programmers out there who can clarify whether longjmp[]ing out of a window procedure is a bad idea?] there are also some places where redisplay may be called where there is a very explicit "prison" put around the code to prevent all longjmp[]s, e.g. modal loops induced by clicking on the menu. the proper solution is either [1] provide a way to restart the throw after all "prison"s have exited (perhaps the best general solution, if it works; but it may have subtle problems; i'd have to think about it; for window procedures it would be tricky because you'd have to figure out all the places where window procedures are called, and continue the throw *outside* of those calls); [2] avoid calling event code that triggers process-handling inside of protected code; in the above message i show how it could be fixed in this circumstance (and probably should; it's unlikely we want to see the progress bar during pre-redisplay update, right?), but the same issue can likely reoccur in a lot of different situations. [3] probably the best solution in this case: in the code that wants to `throw', what it should do instead is check to see whether its throw will succeed, or be caught early (we would have to add a primitive to return this status; it can just look at `inhibit_flags' and should probably return a list of all the flags currently set; we'd also want to consider removing the call to `with-trapping-errors', which is just duplicative). if the throw will succeed, just throw; else, call `enqueue-eval-event' to push an event to be called later. when this is called, it does the exact same thing as before -- check if it's ok to throw, throw if so, else call `enqueue-eval-event' again. (hopefully, you won't get in an infinite loop pushing eval events! i think this won't happen because inner loops are generally waiting for something quite specific; but if this does happen, or you're worried about it happening, instead of pushing an eval event it might work to push a one-shot timeout event for a short time, e.g. 0.1 seconds). ben

Clemens Fruhwirth <clemens(a)endorphin.org&gt; writes: (setq progress-feedback-use-echo-area t) The variable is, of course, misnamed because the "graphical" feedback also uses the echo area.