More unhelpful update descriptions

[Ian Malone]

On 3 July 2013 08:47, Michael Scherer <misc at zarb.org> wrote:
> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
>>
>>
>>
>> On Wed, Jul 3, 2013 at 9:32 AM, drago01 <drago01 at gmail.com> wrote:
>>         On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
>>         <dan.mashal at gmail.com> wrote:
>>         > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
>>         <py at luyten.fr> wrote:
>>         >> Not sure if it makes any sense but maybe could we have
>>         something like
>>         >> "freeze tag changes until desc is better".
>>         >>
>>         >> I propose this because testers will not _really_ want to -1
>>         karma, and
>>         >> as a maintainer it might be a bit hard, but with a good
>>         reminder like
>>         >> "not pushed to stable until desc is better" I would have
>>         made less
>>         >> mistakes
>>         >>
>>         >> yes not being reminded is not an excuse and such proposal
>>         would not save
>>         >> time, still I believe it could help more than hurt
>>         >
>>         >
>>         > There is already a perfect example of this.
>>         >
>>         >
>>         https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
>>
>>
>>         This is also a perfect example of useless "does not fix bug x"
>>         karma.
>>         If it is not *worse* then the previous package there is no
>>         reason to
>>         give it negative karma.
>> If it doesn't fix the bugs, the update should fix, it is appropriate
>> to give negative karma. Otherwise the bugs would be closed, when it
>> becomes stable, but won't be fixed.
>
> That's not what the guidelines say :
>
> https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to
>
>

Quoting:
> If you find an update does not fix a bug it claims to fix, this is not usually a case where you should file negative karma.
> Only file negative karma if that is the *only* change in the update. If an update claims to fix five bugs, but only fixes four
> of them, it is not helpful to post negative karma as this may result in the update being rejected, which does not help
> those suffering from the bug that wasn't fixed, and hurts those suffering from the bugs that are fixed.

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.
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.


-- 
imalone
http://ibmalone.blogspot.co.uk