Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional

[Sam James <sam@gentoo.org>]

Eli Schwartz <eschwartz93@gmail.com> writes:

> On 5/1/24 10:10 AM, Martin Dummer wrote:
>> Since Agostino's tinderbox tests now report qa warning, the group
>> vdr@gentoo.org has 101 open bugs assigned, most of them caused by qa
>> warnings from vdr-plugin-2.eclass.
>> 
>> Many vdr plugins need small adjustments because API or makefile changes
>> in upstream media-video/vdr which can be easily fixed with small changes.
>> 
>> These warnings are only useful for the vdr plugin maintainers, so I
>> propose they should (only) be reported as QA-warnings when the global
>> variable
>>     VDR_MAINTAINER_MODE="1"
>> is set in make.conf
>> 
>> This patch is also put to github in
>> https://github.com/gentoo/gentoo/pull/36504
>> 
>> The PR is lacking many many "Closes: ...." tags, which I will fill in soon.
>> 
>> Any comments?
>
>
> What does "only useful for the vdr plugin maintainers" mean? Why can't
> anyone fix them?
>
> There are lots of QA warnings that a package can generate, and lots of
> them are "only" relevant to someone editing the upstream source code.
> Why should vdr plugins be special?
>
> From a quick glance at the warning messages, my inexpert feeling is that
> two of them are a bit "wishy-washy" and could be classified as "a
> warning to be picky and do best practices":
>
> - gettext handling
> - old Makefile handling
>
> The others seem like worrisome issues that should very much be reported
> in tinderboxes and get fixed.

What we really need is:
a) https://bugs.gentoo.org/162450 to avoid scaring users;
b) possibly some level of QA notice to distinguish between "check this
out" (think e.g. qa-vdb LHS where it _might_ be unused, but not
necessarily), and "this is definitely wrong"

I am convinced we need a), I am not-at-all convinced we need b) - at
least not in terms of whether bugs are reported.

>
> Automatically sed'ing out source code, especially for the one that says
> "please recheck", very much looks like the purpose of the qa warning is
> that the functionality isn't trusted to be correct, is offered on a
> best-effort basis, and needs to be manually reviewed and marked as okay
> (by applying as a real patch) in order to squelch the warnings.
>
> In other words, there are "QA issues" and "QA nitpicks".