From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 51793158064 for ; Thu, 9 May 2024 13:08:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5BEA5E2C65; Thu, 9 May 2024 13:08:50 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E7673E2C57 for ; Thu, 9 May 2024 13:08:49 +0000 (UTC) From: Sam James To: Martin Dummer Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional In-Reply-To: <5354f18f-ee4a-4475-9b7e-6502886335ea@gmx.net> (Martin Dummer's message of "Thu, 9 May 2024 15:02:46 +0200") Organization: Gentoo References: <7e5a29e3-43e4-4af9-b7c5-660501a027a8@gmx.net> <4dc6df27-4efa-47b1-8ddd-4bdd08a08b21@gmail.com> <87cyq3ldah.fsf@gentoo.org> <5803c021-601d-48b2-bbfa-ce5de555e1cf@gmx.net> <87le4ji3ox.fsf@gentoo.org> <5354f18f-ee4a-4475-9b7e-6502886335ea@gmx.net> Date: Thu, 09 May 2024 14:08:46 +0100 Message-ID: <87fruri141.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: 85cb53e6-45f5-40f8-8338-70e9138bac6b X-Archives-Hash: 6b440e9791028a9829f41a7975b16592 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.