Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Am 09.05.24 um 15:08 schrieb Sam James: 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. I changed https://github.com/gentoo/gentoo/pull/36504 accordingly and added the "Closes:" tags. Can you please review?
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Martin Dummer writes: > Am 09.05.24 um 14:13 schrieb Sam James: > > Martin Dummer 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. 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.
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Am 09.05.24 um 14:13 schrieb Sam James: Martin Dummer 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.
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Martin Dummer writes: > 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. Right, that's why I didn't say "we can just use". > > 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 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.
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
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.
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Eli Schwartz writes: > On 5/1/24 10:10 AM, Martin Dummer wrote: >> Since Agostino's tinderbox tests now report qa warning, the group >> v...@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".
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
On 5/1/24 10:10 AM, Martin Dummer wrote: > Since Agostino's tinderbox tests now report qa warning, the group > v...@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". -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
