More unhelpful update descriptions

[Ian Malone]

On 3 July 2013 20:48, Adam Williamson <awilliam at redhat.com> 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