On Sat, 14 Apr 2012 16:47:36 +0100 Colin Watson <[email protected]> wrote:
> On Sat, Apr 14, 2012 at 04:15:16PM +0100, Neil Williams wrote: > > On Sat, 14 Apr 2012 15:05:14 +0200 > > Luca Capello <[email protected]> wrote: > > > What is the rationale against simply closing the bug without touching > > > the reported version? > > > > For the benefit of the bug report, this was done so that the bug can > > be closed with -done instead of the deprecated / special purpose > > -close. > > Last I checked - and admittedly it's a little while since I was really > an active BTS administrator, but the current documentation seems to > agree with me - the -done and -close addresses were synonymous, and > neither was deprecated. Perhaps you're thinking of the 'close' command > to control@bugs and the prefixed '-' was a typo. Ah, OK. I think I had -close == close in mind. > Rather than removing the found data, it's more usual to mark the bug as > (pseudo-)fixed in a version that's slightly greater than the last one in > the archive. The current convention is to mail -done/-close with the > following pseudo-header at the start of your e-mail body: > > Version: 0.3.13-5.1+rm > > This would actually have been less effort as you wouldn't have had to > duplicate all the bug numbers between the To: line and all those > 'notfound' commands. Nowadays, dak can be told to do this when removing > packages, and you can see the code and e-mail template it uses here: > > http://anonscm.debian.org/gitweb/?p=mirror/dak.git;a=blob;f=dak/rm.py > > http://anonscm.debian.org/gitweb/?p=mirror/dak.git;a=blob;f=templates/rm.bug-close-related For whatever reason, dak didn't send those emails when the package was removed - in the case of the entire opensync removal, that was because there were so many packages to remove that ftpmaster recommended a single RM report using multiple entries in the title but that hits a bug in dak which won't send the bug reports for multiple RM requests in the same operation. :-( So, after doing all of this for the opensync bugs (which was ~100 bugs), I followed the same method for this package when I found it listed in the QA page about bugs without maintainers. I could have used +rm but that seemed a little misleading as most people will interpret that as the output of dak. > > I don't see what purpose the found status field will achieve once the > > bug is archived as the package does not exist in Debian. > > I agree that it's a bit academic, but perhaps the argument that the > usual convention is actually less effort will be persuasive :-), along > with matching what dak does. In general (although perhaps not in this > specific case) we like to keep the found versions around in case the > package is ever reintroduced. Usual convention, yes, probably. I was more trying to avoid making my cleanup look like the dak operation which somehow went awry originally. If I have to do this again in future, I think I'd probably use +qa. TBH, I don't mind either method, this kind of task is only needed relatively rarely. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgphVsHRbXR7v.pgp
Description: PGP signature
