[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

>>>>> "Santiago" == Santiago Vila <sanvila@unex.es> writes:

    Santiago> Well, I consider the idea that old bugs deserve more
    Santiago> attention than new bugs (or non-old bugs) completely
    Santiago> flawed.

I wonder how many old bugs are either fixed (but not marked as fixed)
or irrelevant (if another solution was used).

I suspect that there would be a high percentage of such bugs.

    Santiago> Bugs do not increase their severity by age. A wishlist
    Santiago> bug which is ten years old is still a wishlist bug. A
    Santiago> normal bug which is ten years old is still a normal
    Santiago> bug. An important bug which is ten years old is still an
    Santiago> important bug (well, modulo the fact that the important
    Santiago> severity might not exist ten years ago :-).

True. However, I think it is easy to forget about old bugs and
concentrate only on the new.

After all who wants to spend considerable time gong over old bugs,
attempting to work out if they are still relevant, for situations that
you are never likely to encounter yourself, when you could be fixing
"real" problems (as in problems that effect you)?

Maybe the process of reviewing old bugs could be improved. I find the
current process very clumsy:

1. Review bugs in web browser.

2. Identify questionably bug that you haven't already looked at before

3. Inspect bug report, in new window, install package, install source,
   inspect as required. Open up new browser windows to find
   information as required.

4. Make changes as required to source code.

5. Enter one/more emails to either forward bug upstream, change tags,
   or close the bug.

6. Go back to step 3.

7. Fix up the all the silly typos made in every BTS email sent so far
   and retransmit. (note: this is after the BTS has decided to

8. upload the changes to source code.

9. realize that I forgot to sign the upload due to a bug in by
   pbuilder wrapper script, create a *.commands file to send to the
   upload queue to delete the old upload and reupload again.

It would be good if this process could be simplified and/or made more
error resistant. For example:

1. Client program that lists all bugs and has the ability to mark
   bugs. Ability to sort bugs in order of when you last looked it one.
   This information should be stored on maintainers computer, not the

   Even better, if you could attach a short summary/note to each one
   for your use, e.g. "need to talk to XYZ about this", "this user is
   an idiot", "I think this has been solved but I need to check X
   first", or "as of 1/1/2005 this bug is still waiting on X" that
   you don't want to appear in the BTS. This should be immediately
   visibly without having to select the bug and scrolling to the

   This way you can get a clear picture of which bugs require
   immediate attention, and which bugs you consider "too-hard" or
   "too-time consuming" right now, or are waiting on other outside

2. Client program with provision for sending updates to the BTS, but
   caching the updates until they finally appear in the BTS. Either
   that or fast response time from the BTS.

3. Environment/scripts to enable better testing, updating, and
   recompiling packages even if it is based on a non-preferred
   distribution, e.g. if you use stable, but the bug report is against
   unstable or vice versa.

   pbuilder is good and building packages against other distributions,
   it is not so good (at the moment anyway) for testing arbitrary
   packages in arbitrary distributions (except via pre-written
   scripts), because it was designed for building not interactive
   testing. There is the "pbuilder login" operation, but it doesn't
   give you access to your newly created package.

4. Make dupload obsolete, and replace with dput. Make dput the default
   in debrelease. I think dput would have prevented me uploading my
   unsigned package.
Brian May <bam@debian.org>

Reply to: