Le Mer 3 Mai 2006 14:28, Christoph Berg a écrit : > Automatically setting the 'fixed-upstream' tag is certainly a very > nice idea that no one will object to. > > For 'upstream', I don't really see a benefit of setting it since the > bug is already marked as forwarded. I would just leave it alone not > to interfere with anything the maintainer would want to do with the > tag. (Not that I could think of anything reasonable at the moment, > but still.) > > For 'wontfix', I would make sure bts-link doesn't play set-unset > games, so it only sets/unsets the tag when the upstream state is > actually changed. well, my view is the following. When a bug has: * (+upstream +wontfix): it means, upstream wont fix that bug. * (-upstream +wontfix): Maintainer does not want to fix the bug. forwarded already either means: * that the Maintainer does not want to fix the bug already, so wontfix is a free tag to specify other things. * or for Done bugs, that the bug is fixed in debian by the Maintainer, and that he pushed the patch upstream, and states he forwarded it. That's why for me, as soon as a bug is forwarded, the 'wontfix' tag, does not makes sense anymore. Here is how I understand tags, and that should explain why I use them that way. The thing is I could use *only* usertags, and never mess with classic debbugs ones. But those does not appear on the BTS, and a very valuable informations would be lost. > My 2¢ on this... Oh, and thanks for implementing this service :) You're welcome Le Mer 3 Mai 2006 14:44, Martin Michlmayr a écrit : > Unfortunately, there are always corner cases. What if upstream marks > something as fixed, you get a Debian bug report that the bug is still > there and you mark it as forwarded to the original bug report, waiting > for it to be reopened. In the meantime, the tool will tag the bug as > "fixed-upstream" which is obviously wrong. > I just removed a fixed-upstream tag from a bug but I fear the tool > will set it again. (But yeah, I know I should get upstream to reopen > it or file a new one or something. Unfortunately it's one of these > bugs where people disagree whether it's a bug or where the bug is.) IMHO, in his case, he should remove the forward, tag the bug upstream, and mention in the bug history that this is related to the upstream bug "foo". set the forwarded state of a bug does not makes sense to me, if you dont adhere to how upstream deals it. We could also think of a way to alter the forward to say to btslink that he should not sync that bug, maybe by adding a &btslinkignore to the url, but that's not very pretty, and puts overhead on the maintainers where I try to remove some. of if the upstream reopen the bug, that will remove the fixed-upstream. It only gives hints of the bug that are likely to be closed upstream for your next upload. It tighten the list of bugs to check a lot. Le Mer 3 Mai 2006 14:56, Andreas Barth a écrit : > Basically, the tool should just work on *changes* upstream, i.e. if > upstream goes from reopened to resolved/fixed. Which would mean that btslink would have to keep a local database of the upstreams statuses, which I wanted to avoid, because it's fragile IMHO, and moreover it's hard when you deal with a given forwarded bug to know what to do. And honnestly, the only real problem is when a debian developper disagrees with what upstream does. In that case I strongly think that 'forwarded' becomes inappropriate, and as it's what triggers btslink ... -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgp9RshPWcA7J.pgp
Description: PGP signature