Russ Allbery <r...@debian.org> writes: > Anton Gladky <gl...@debian.org> writes: > >> Ok, I canceled the upload. > >> We cannot postpone Wheezy-release, waiting for every upstream's >> decision. If the solution works, why should not it be applied? >> Otherwise the package should be removed from testing.
The solution may work, but if upstream deems the code insufficient it might be because of some very important reasons. For example, it might make this specific situation work, but breaks other things, or only works for one case, but not another, or many other possible reasons. For this issue, what caused this upstream was a fix for another issue, and I am not sure that the proposed fix will cause the original issue to re-appear, I dont want a regression for that issue to come up as a result. I don't think it is such a great idea to stuff something into the Debian package that upstream has a problem with, it tends to make upstream unhappy when they have to deal with the fact that it exists in the Debian package for years. In particular I'm thinking of how great they have been when security issues have come up and they've produced backports of fixes for the versions that we carry. If their backports aren't going to work because we decided to put in some code that they didn't like in the first place, how do we deal with the security fix then? > The problem is mildly obscure (many Puppet manifests, including very > complex and non-trivial ones, will never trigger this error condition) and > absolutely does not warrant removing the package from testing. In fact, > I'm tempted to downgrade it to important again, although if there is a > tested upstream fix, I'd be in favor of applying it for wheezy. I have to agree with Russ, this is a kind of weird corner case. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org