In managing similar situations in the past, involving projects with a large legacy codebase that had been migrated through some upheavals, I have found that it is sometimes best to be draconian about old legacy bug reports.
Basically, pick a date threshold and a priority threshold and close everything that isn't newer or more critical. The philosophy has three points: 1) If the bug is already fixed through some other issue, obviously there is no need to keep it open. 2) If the bug is so minor that no one has deigned to fix it, it maybe doesn't need to be open. 3) If the bug is important enough that someone will want it fixed, a newer bug will be created. This can really help clean up the open issue list dramatically and help avoid getting overwhelmed by the sheer mass of legacy issues. It obviously helps with prioritization. Just a hopefully helpful suggestion. -Mel -----Original Message----- From: Jukka Zitting [mailto:jzitt...@adobe.com] Sent: Monday, November 29, 2010 6:36 AM To: dev@pdfbox.apache.org Subject: Re: JIRA bug cleanup? Hi, On 29/11/10 11:43, martijn.list wrote: > JIRA contains a lot of bug reports (410 open bugs) which are probably no > longer valid because the bugs have already been fixed. I have looked to > a couple of them an most of the bugs were already fixed. I think it > would be a good idea to take some time to close the bugs that are either > fixed or are really old. +1 We still have a lot of old and not that well categorized bug reports that we migrated from SourceForge a few years ago. I believe many of those bugs have already been fixed in trunk. Others should probably be resolved as incomplete if there's not enough information to determine whether the bug still occurs in trunk. > I have already commented on a couple of bugs that the bug has already > been fixed but only the person(s) responsible for bug management can > close the bugs. I added your Jira account to the "Contributor" role for PDFBOX, so you should now be able to also resolve issues. BR, Jukka Zitting
smime.p7s
Description: S/MIME cryptographic signature
