Am 09.05.24 um 14:13 schrieb Sam James:
Martin Dummer<martin.dum...@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.
