Manoj Srivastava <[EMAIL PROTECTED]> wrote: > Let us see how relevant this is Here are my list of resolved > bugs. Let us see.. > > 29 bug reports. > 2 cases whre reproducers were possible, one whereit is available > 6 possible test, with 3 being noted as tricky > 23 cases where one could put thinkgs on a checklist, 9 cases where it > just clutters things up. Therefore only 14 out of 29 cases that even > a checklist makes sense. > > That is less than 50% of my closed cases warrant even a > checklist item ... > No, I strongly object to bureaucratic junk required just to > close bugs, given that not all cases could one even create a > checklist item.
Ok, I've looked over your examples, and I somewhat agree. Basically, there were several categories of "bugs" (1) Non-bugs. These shouldn't go on any kind of checklist, but maybe are FAQ material. (2) Documentation bugs. Oddly enough, these should be treated the same way as non-bugs. (3) package/process/distribution bugs. These warrant special handling. (4) Bugs where the code doesn't perform properly. These should get listed or have a test made. Here's how I'm thinking...: > #25609: Gnus: prerm script failure make it impossible to upgrade/pruge > Package: gnus; Severity: important; Reported by: Manoj > Srivastava <[EMAIL PROTECTED]>; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: rewrote scripts totally. > Reproducer: no > Test: no > Checklist: What do we checklist? That the old scripts have not come > back? That prerm doesn't needlessly fail. This is almost generic enough that it should go in lintian, but a safe test would need to be package specific. > #25585: gnus depends on xemacs20, but xemacs20 doesn't exist > Package: gnus; Reported by: Matthias Klose > <[EMAIL PROTECTED]>; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: Emacs20 now available > Reproducer: no > Test: no > Checklist: no Administrative issue here: We do need something to check distribution consistency, so this makes sense to be checked by ftp.debian.org. I guess the underlying points are: (a) It just matters if the bug in *a* checklist, if it's already on a checklist it doesn't need to be added again. (b) It doesn't have to be a checklist specific to the current package. (c) If a bug is reported by an automatic system, it doesn't need to go on a checklist [clearly, it's a known condition]. > #26536: gnus: /usr/lib/emacsen-common/packages/remove/gnus > should return 0 if it does nothing > Package: gnus; Reported by: [EMAIL PROTECTED]; Done: Manoj > Srivastava <[EMAIL PROTECTED]>. > Solution: Added a return 0 > Reproducer: not applicable > Test: I guess so but is tricky, > Checklist: One could, but it would only clutter up the real tests Something I don't understand here: is this a dpkg/debian issue or a gnus issue? I agree that dpkg issues warrant their own checklist. > #27186: pkg-order: pkg-deptree can't handle "libstdc++2.8" > Package: pkg-order; Reported by: Richard Braakman > <[EMAIL PROTECTED]>; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: pilot error > Reproducer: not applicable > Test: no > Checklist: no Yeah, if it's not a bug it doesn't go on a checklist. Maybe gets added to the "potential FAQ" queue, though. > #27311: kernel-package: flavours code broken > Package: kernel-package; Reported by: Jonathan H N Chin > <[EMAIL PROTECTED]>; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: rewrote code > Reproducer: no > Test: no > Checklist: I guess. ?? To test this you'd compile a kernel and ensure that it shows up in the proper place. Compiling a kernel is slow, and this is a fairly trivial check, so maybe there should be a trivial kernel to excercise the code against. But I see no problem with putting this on a checklist. > #27450: latex2html: problem with -html_version 3.2,math > Package: latex2html; Reported by: <[EMAIL PROTECTED]>; Done: > Manoj Srivastava <[EMAIL PROTECTED]>. > Solution: pilot error > Reproducer: no > Test: no > Checklist: no Sure, non-bugs don't go on bug checklists. See above. > #27521: psgml: Should psgml pre-depend on autoconf? > Package: psgml; Reported by: [EMAIL PROTECTED]; Done: Manoj > Srivastava <[EMAIL PROTECTED]>. > Solution: run autoconf on machine before packaging > Reproducer: no > Test: no > Checklist: I guess? Test would be to install it on a system which doesn't have autoconf. One of the things I've been thinking about is setting up a system with a disk image which contains just the debian base. And another disk which that can be copied on to. And a serial console so that it can be driven by an expect script off another machine. This system should then cycle through the debian package list: setting itself up as just the base with one package selected, then try to install the package. If installation fails, it should file a bug report. As a general rule, it should only test each package release once [except through manual intervention]. Packages with configuration questions at install time probably need to be installed several times with several different configurations. This would require some manual work to set up. Some packages are dangerous enough that they couldn't be tested by this process. They should probably be specially marked, because if they're a problem for an automated process they'll probably be a problem for a number of users. As long as we have this marked down as a plan, this class of bugs is checklisted [and if we can actually implement it we're way ahead of the game]. > #27610: latex2html cannot be installed non-interactively > Package: latex2html; Reported by: > [EMAIL PROTECTED]; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: Made install not ask question > Reproducer: no > Test: no > Checklist: One could, but it clutters up the checking process True. In any event, this is more of a dpkg or installation time issue than a package specific issue. > #28451: cvs-buildpackage: README seems to be wrong > Package: cvs-buildpackage; Reported by: "Marcelo E. Magallon" > <[EMAIL PROTECTED]>; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: rewrote docs > Reproducer: no > Test: no > Checklist: One could, but it clutters up the checking process Yeah, documentation bugs aren't testable. They need to just get marked noted in the changelog. > #28452: cvs-buildpackage: spell check > Package: cvs-buildpackage; Reported by: "Marcelo E. Magallon" > <[EMAIL PROTECTED]>; Done: Manoj Srivastava > <[EMAIL PROTECTED]>. > Solution: fixed > Reproducer: no > Test: no > Checklist: no Same here. etc. -- Raul
