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

Bug Tags

Hello world,

Thanks to the tireless and heroic efforts of Adam Heath and yours truly
(yes, you may applaud now, bouquets accepted also), the BTS should now
support "Tags" for bugs. Each bug can have zero or more of a set of
given tags. These tags are displayed in the list of bugs when you look
at a package's page, and when you look at the full bug log. The current
bug tags are:

		A patch or some other easy procedure for fixing the bug is
		included in the bug logs. If there's a patch, but it doesn't
		resolve the bug adequately or causes some other problems, this
		tag should not be used.

		This bug won't be fixed. Possibly because this is a
		choice between two arbitrary ways of doing things and
		the maintainer and submitter prefer different ways of
		doing things, possibly because changing the behaviour
		will cause other, worse, problems for others, or possibly
		for other reasons.

		This bug can't be addressed until more information is
		provided by the submitter. The bug will be closed if the
		submitter doesn't provide ore information in a reasonable
		(few months) timeframe. This is for bugs like "It doesn't
		work". What doesn't work?

		This bug can't be reproduced on the maintainer's system.
		Assistance from third parties is needed in diagnosing the
		cause of the problem.

		This bug is fixed or worked around, but there's still an
		issue that needs to be resolved. (This will eventually
		replace the "fixed" severity)

		This bug affects the stable distribution in particular.
		This is only intended to be used for ease in identifying
		release critical bugs that affect the stable distribution.
		It'll be replaced eventually with something a little more
		flexible, probably.

Severities can be set by sending a message to control@bugs.debian.org with
lines like:

	tags 74318 - wontfix
	tags 74318 + patch, unreproducible
	tags 74318 = stable, moreinfo

(to respectively subtract tags, add tags, or ignore the current tags and set
them afresh. If you forget the [+-=], it'll default to +. Hi Manoj)

If you merge bugs with tags, each bug will get all the other bugs' tags.

You can't set a tag more than once.

You can set tags on an initial report with a pseudo-header like:

	Package: foo
	Tags: patch, stable

although the control interface is probably more useful.

This is the only documentation for tags atm. That should be fixed. There's
also no way to query "all open bugs with the patch tag, older than a
month" at the moment, you have to eyeball the bugreports for each package
to work the above out. Bugs also aren't split based on tags, so rather
than a list of unreproducible bugs, followed by a list of bugs with
patches, followed by a list of fixed bugs, followed by any other bugs,
they'll all be mixed together.

Suggestions on good ways of querying or displaying tags appreciated. I'm
not sure of any elegant ways of separating bugs with patches (easy to fix)
from unreproducible / moreinfo bugs (not worth looking at for the moment)
when there might be bugs marked "moreinfo, patch", eg.

We return you now to your regularly scheduled weekend lull.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgpjjZg79Pnjw.pgp
Description: PGP signature

Reply to: