Date: Mon, 4 May 1998 18:53:09 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Randall Hopper <rhh@ct.picker.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/5296 Message-ID: <199805042253.SAA21201@brain.zeus.leitch.com> In-Reply-To: Jordan K. Hubbard's message of "Mon, May 4, 1998 13:19:31 -0700" regarding "Re: bin/5296 " id <6821.894313171@time.cdrom.com> References: <199805041546.LAA16661@brain.zeus.leitch.com> <6821.894313171@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Mon, May 4, 1998 at 13:19:31 (-0700), Jordan K. Hubbard wrote: ] > Subject: Re: bin/5296 > > You've missed the point - it has nothing to do with hardware > limitations and much more to do with the fact that GNATs is just > basically unwieldy at handling this many. It may have a wonderful > priority matrix, but actually searching through and locating such PRs > is a real pain. I didn't think hardware or other system resources was the problem. In that case I'm not sure why you're finding it a "real pain" to search and locate "such" PRs. The current WWW summary report is indeed practically useless (except as a large and searchable summary report, assuming the synopsis text is meaningful), and the "formulate a specific query" page (which can only be linked to from the summary report and not from the "Support" page) doesn't sort by priority or severity, but anyone with direct GNATS access should be able to use either the query-pr command-line, or whatever front-end, to generate a very selective set of PRs. No matter what system you find, effective use of it in face of such a large user-base and potentially large number of submissions will require that you have energetic, knowledgeable, and dedicated people like phk to read through all submissions and re-file them with appropriate adjustments to the priority, severity, and/or class fields. I think a full-text search capability for PRs would help reduce the number of duplicates too. (glimpse and the WWW tools available for it should do fine, though the doing the right interface would probably take some development effort -- simple grep searches would probably require too much horsepower) > > In addition I hope it isn't necessary to point out that GNATS is free > > software and is in fact quite easy to modify and/or extend. It's not > > Easy when you have the time and resources, sure. :( Wouldn't it be more effective to enhance GNATS to the state where it is usable for your requirements rather than first finding (or worse designing and implmenting) some other tracking system (even if it's simply a separate GNATS database) and then moving all the "low-priority" PRs over to that new system? (Assuming it's GNATS that actually need enhancing, and not just its pattern of usage....) As you suggested in jest earlier, the only alternative is to wipe the slate clean and start fresh with new rules, systems, or whatever, and I think we all agree, esp. the collective group of submitters, that this is just not a viable alternative at this stage. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805042253.SAA21201>