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

Re: Closing bugs in BTS



In article <[🔎] 20050824235940.59f516dd@pirx.vlan> verdan@pirx.int.pl writes:
>In recent announce about changes in BTS (Subject: BTS version tracking
>Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new
>versioning system. I'm not sure if sending mail to bug.no-done@b.d.o is
>now prefered way to closing bug rather than closing it in Changelog ?

If the bug is fixed by an upload, close it in the changelog.
If the bug is fixed some other way, or the change has already been
uploaded, use the nnn-done address with a version pseudo-header.

>(I conclude that it is not possible to close bug for specific version,
>in testing, unstable and allow to remain opened in stable closing via
>Changelog, am I right ?).

Closing it in the changelog will mark it fixed in that version.

>Moreover I wonder if when closing via mail should I write in Changelog
>sth like: this upload fixes bug number 1234567 in testing and
>unstable which has been closed via mail, and add tag sarge to bug that
>remain opened in &dist=3Dstable ?

No, use the found and notfound BTS commands to mark what package
version the bug applies to if needed.

You can even keep track of bugs fixed in multiple versions.  (Mainly
for release-critical bugs fixed by security/proposed updates.)

>Next issue I wanted to discuss is information on the page generated by
>BTS.

The bug by default applies from the version reported until the version
it is fixed in.

>Thanks in advance for answering my mail and sorry for taking Your time
>if I really omitted some part of documentation or so !

The version tracking stuff is new and may still have a few rough edges.
It is documented on http://www.debian.org/Bugs/
-- 
Blars Blarson			blarson@blars.org
				http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.



Reply to: