On 3 July 2013 20:48, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On 2013-07-03 2:28, Ian Malone wrote: > >> Tooling issues aside (and it is undesireable that bugs should get >> marked fixed if they haven't been) I think this rule is wrong under a >> strict reading. If an update claims to fix two bugs and fixes neither >> then neither is the *only* change (highlighting is on the guidelines >> page), yet obviously the rationale for this rule does not apply in >> that case. > > > I was kinda hoping people would be able to draw the obvious interpretation > there. That page (like just about everything I write...) is too long > already, I really don't want to make it any longer. > I think the intent is pretty clear, but the wording is slightly contradictory. It could probably be tidied up without making it longer, but exactly how depends on this: > >> Pedantry aside, there is another case: where the update is meant to >> fix a bug and the maintainer has tried to do this by pulling in an >> upstream update that might not otherwise have been picked up (e.g. a >> git hash which has added a feature in the process of fixing the bug). >> The upstream update might be part of the change, but it was not the >> purpose of the change. > > > I'm not sure what conclusion you're drawing here? > > Well in such a case (and I've been in one, quite a while ago), there's a bug (in that case a kernel bug). The maintainer is trying to fix it and produces an update. It doesn't fix the problem, it is technically a newer version that might not have been packaged otherwise. There is a cost to having this pushed out and everyone updating for no benefit. Or maybe more concretely this (picked at random, I'm sure it probably fixes what it's meant to): https://admin.fedoraproject.org/updates/libdrm-2.4.46-1.fc19 (In this case there's no BZ, so it might not have been reported in Fedora.) This pulls an upstream update to fix a bug. In such cases it's probably known that the upstream update does fix the issue. But if it turns out it doesn't when tested then maybe something has gone wrong with the update or the bug wasn't really fixed upstream. It looks pretty clear here since it's listed as a bugfix and a single issue, if you were testing it then you would give it a -1 if it failed to fix qxl cursor bugs. However, if this was kernel 3.9.7 (which doesn't seem to have been packaged, went 3.9.6 -> 3.9.8) which had been built as a bugfix for a single bug which it didn't fix should it be -1ed? I'm not really arguing either way, I generally only test packages on bugs I'm subscribed to, but I suspect cases like often rely on some alternate-channel communication between the tester and the maintainer, whether through bugzilla or mailing lists. (Of course in the multiple bugs case I'd just report it on the BZ entry that the update hasn't made an improvement.) -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
