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
today.
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
respond).
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
BTS.
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
bottom.
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
events.
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: