Front page | perl.perl5.porters |
Postings from December 2000
Re: bug db cleanup time
From: H . Merijn Brand
December 7, 2000 07:39
Re: bug db cleanup time
Message ID: 20001207162625.E859.H.M.BRAND@hccnet.nl
On Wed, 6 Dec 2000 17:09:40 -0600, Jarkko Hietaniemi <firstname.lastname@example.org> wrote:
> Thanks to many volunteers the number of open bugs in the bug db
> (http://bugs.perl.org/) has dropped to around one thousand.
> Which is nice and certainly better than, say, two thousand.
> I think we can easily cut the number of the open bugs by several
> hundreds in very short time, though.
> The problem are the bugs in the bug process, I think... what I mean
> is that once a bug has been submitted there is no automatic periodic
> feedback back from us to the bug submitter.
Since assigned a bugmeister, I've been digging in open bugs for HP-UX and AIX,
and in some cases, I've contacted the original submitter (there's probably no
use in contacting email@example.com), which lead to only one bug being closed.
Now I've closed
20000608.001 "}" in format fields
I wanted to close more, but some other bugmeisters beat me to that ;-)
> A bug may easily be lost in the shuffle: the bug may be so esoteric
> that right then no one has anything bright to comment, or someone who
> would know is at that moment too busy to answer, or whatever. What
> would be nice is some sort of periodic automatic polling back to the
> submitter: has the bug been addressed/resolved? Did anyone human ever
> reply to you? Have you in the meanwhile found anything related to the
> bug, possibly found a workaround or created a patch? Also, there is
> no guarantee that when a bug gets fixed the report gets closed.
> I *try* to do that but I'm fully fallible.
I've tried to reproduce buggy code snippets supplied in the bug reports, but
most of the reports only `describe' the problem, or are (or seem to be) very
system dependant. For working snippets, most of the open bugs where still
showing the described flaws.
> As a result of these deficiencies there are now numerous open "Not OK"
> message accumulated during the 5.7 (and even 5.6) development cycles.
> I do appreciate them, I really do, but the open bugs report also bother
> me a lot, they really do.
> Now, in the short term, what I would dearly like to see is that those
> who see this message and know that they have submitted "Not OK"
> messages would in the past, would go to the bug db website, and search
> for any of their open bugs. Select Search, Status open, Source addr
> something that matches your email adddress, and hit "query". Which of
> the resulting bug reports can be closed? Send the ids of the clearly
> obsolete ones directly to me, I'll close them (or, if you happen to
> have bug db admin rights, you can close them yourself...) If any of
> the open ones have mutated since you submitted them, please close
> the old ones and submit fresh ones. If any of them are really still
> acute, please try to investigate further, ask p5p for help if needed.
My search utility for scanning a local copy of the perlbug database (bugtk)
using perl/Tk has reached a state where all above is possible. Latest version
(1.05) is just sent to Richard, but if there are more people wanting to use it
instantly, I'll make it available either here on on the web.
> While you are at it, you could try drilling down the list of 'high'
> and 'medium' severity bugs. If you see something that you know has
> been fixed, either in 5.7, 5.6, or even earlier, don't hesitate to do
> something about closing the bug. If you start feeling that being bug
> db admin would be a neat thing, ask firstname.lastname@example.org for admin rights.
> In the long term: any further ideas on the bug fixing cycle and its
> problems are welcome. One idea I have would be to arrange 'bug
> interest lists', mailing lists that would automatically receive for
> example bugs on a platform X.
H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.005.03, 5.6.0, 5.7.1 & 620 on HP-UX 10.20 & 11.00, AIX 4.2 & 4.3,
DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify