On Fri, Jul 29, 2005 at 02:38:19AM +0200, Mathias Weyland wrote: > I don't understand what the 'sid' tag is for and who is allowed to set it. > Bug #318692 and #320218 have been assigned to the packages xlib-dev, > bookmarkbridge and 3ddesktop. Both of those bugs deal with changing > build-deps for Xorg. Since we already have a 3ddesktop package with fixed > dependencies ready for upload (see pending bug #319120) I reassigned the > two bugs to the packages bookmarkbridge and xlib-dev. (This seems easier > to me than cloning the bugs, reassigning the clones to my package and > merging them with the pending bug). > During this procedure, I noticed that bug #318692 and #320218 were tagged as > 'sid'. I wrongly admitted that the 'sid' tag was for sid what the 'sarge' tag > is for sarge and the 'etch' tag for etch: A tag which marks that the bug > applies to sid. I knew that the 'sarge-ignore' and 'etch-ignore' tags should > only be used by the release managers. To make sure that this is not the case for the > 'sid' tag, I checked [0] and saw that there were no such restrictions. I > wanted to tag bug #319120 as 'sid', but it failed (see [1]): > # Automatically generated email from bts, devscripts version 2.8.14 > tags 319120 - sid > Is it possible that I am not allowed to set the 'sid' tag on bugs of my > packages? If yes, this should be documented in [0] as it is for the > '*-ignore' tags in my opinion. > The second thing I don't quite understand is the description of the 'sid' > tag (also in [0]): > This bug particularly applies to an architecture that is currently > unreleased (that is, in the sid distribution). > I didn't quite understand the meaning of the clarification in the brackets, > to I checked the German version of the page and still didn't understand it > (even though I'm a native German speaker). Then I checked the French version > and things became clearer. I routinely ignore the official description of the "sid" tag here, because there are other applications of it that are far and away more useful than tagging a bug as being specific to an unreleased architecture -- not least of all because tagging an RC bug "sid" doesn't stop the RC bug from holding updates out of testing, so all such bugs are listed as severity: important instead. So, using the "sid" tag to denote bugs that are specific to sid is correct, although in the case where a bug is specific to a *version* of a package that's in sid, the tag is deprecated in favor of the BTS version support. The problem here is that this bug is *not* confined to sid; there is in fact only one RC bug here in spite of the various bug splits/merges/duplicates, and if the conclusion is that it's a 3ddesktop bug (instead of a xlibs-dev bug as I've argued), then there's nothing that would prevent this bug from also reaching etch, and tagging it 'sid' would mean it is no longer being tracked as an RC bug affecting etch. There's certainly nothing wrong with you using the sid tag, it's just a problematic tag to use right because of the above issues. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature