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.
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".
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.
Am 03.05.24 um 06:39 schrieb Sam James:
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.
AFAIS https://bugs.gentoo.org/162450 is not implemented.
Maybe we can agree that the qa-warnings in vdr-eclass make more sense if i change them to "eawarn" or "einfo"?
In my opinion, most plugins in the vdr context will practically not develop any further anyway. It is more important to
keep the current status of vdr-software in the ecosystem up to date as well as possible.
So I need a practical useful approach instead of a fundamental discussion please.
Am 09.05.24 um 14:13 schrieb Sam James:
Martin Dummer <martin.dummer@gmx.net> writes:
Maybe we can agree that the qa-warnings in vdr-eclass make more sense if i change them to "eawarn" or "einfo"?
Sure, make them eqawarn.
Hmm - current state of vdr-plugin-2.eclass is: there are many "eqawarn" in there.
In my opinion, most plugins in the vdr context will practically not develop any further anyway. It is more
important to
keep the current status of vdr-software in the ecosystem up to date as well as possible.
So I need a practical useful approach instead of a fundamental discussion please.
My point is that the QA warnings should exist, and you can worry about
making them "developer-only" in future. Right now, they seem useful, and
the things they flag need to be addressed.
Basically yes, but here (vdr-plugins) the qawarn are used more in a way "to remind the plugin developers to adapt their
sources to newer vdr build environment" or "the way i18n implemented has changed"
The eclass fixes these problems with standardized quirks, the "equawarn" messages show when these quirks are applied.
IMHO its not necessary to tell that to any user, only for interested packagers when they are bored and look out for some
extra work. That's why I made the warnings conditional, printed out when the variable "VDR_MAINTAINTER_MODE" is set to a
not-empty value.
Finally, I am interested in an opinion whether this is acceptable or not, otherwise I tend to remove the warnings at all.
Martin Dummer<martin.dummer@gmx.net> writes:
Maybe we can agree that the qa-warnings in vdr-eclass make more sense if i change them to "eawarn" or "einfo"?Sure, make them eqawarn.
In my opinion, most plugins in the vdr context will practically not develop any further anyway. It is more important toMy point is that the QA warnings should exist, and you can worry about
keep the current status of vdr-software in the ecosystem up to date as well as possible.
So I need a practical useful approach instead of a fundamental discussion please.
making them "developer-only" in future. Right now, they seem useful, and
the things they flag need to be addressed.
It sounds like maybe you want to turn these into log messages (einfo - https://devmanual.gentoo.org/ebuild-writing/messages/index.html), and
drop the "QA notice" prefix.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 399 |
Nodes: | 16 (2 / 14) |
Uptime: | 101:48:54 |
Calls: | 8,363 |
Calls today: | 2 |
Files: | 13,165 |
Messages: | 5,898,006 |