From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5AEF4138247 for ; Sat, 28 Dec 2013 18:12:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 85531E09FB; Sat, 28 Dec 2013 18:12:36 +0000 (UTC) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by pigeon.gentoo.org (Postfix) with ESMTP id 56C4AE07FE for ; Sat, 28 Dec 2013 18:12:35 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by gerard.telenet-ops.be with bizsmtp id 76Ca1n00s2khLEN0H6CaQ9; Sat, 28 Dec 2013 19:12:34 +0100 Date: Sat, 28 Dec 2013 19:12:11 +0100 From: Tom Wijsman To: patrick@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog Message-ID: <20131228191211.220f0984@TOMWIJ-GENTOO> In-Reply-To: <52BF09D7.3060508@gentoo.org> References: <20131225095020.A91BE2004C@flycatcher.gentoo.org> <52BACEE8.1010006@gentoo.org> <52BADA97.8010600@gentoo.org> <52BC2E30.9080006@gentoo.org> <20131226132724.6b9477af@googlemail.com> <52BEEA2D.2020103@gentoo.org> <20131228173502.224c9f96@TOMWIJ-GENTOO> <52BF09D7.3060508@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Cw7Ybmj8T08oGT=Ftxp2DbK"; protocol="application/pgp-signature" X-Archives-Salt: e428ff39-9146-4b3f-b821-c508d6cec51c X-Archives-Hash: 58676a2857f92df81ce80dc5cd518e71 --Sig_/Cw7Ybmj8T08oGT=Ftxp2DbK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 28 Dec 2013 18:26:47 +0100 Patrick Lauer wrote: > > The discussion is based on some questions that are hard to agree on: > >=20 > > 1. How much of a problem is an unused USE flag in metadata.xml?=20 >=20 > Cosmetic issue. No functional impact. This is a description of an unused USE flag instead of an answer; asked differently, how much does its presence impact quality? > > 2. Should such repoman warnings be fixed? By whom? When? How? >=20 > Yes. You see it, you fix it. Once I get around to them, but there are more important things to do. > Not fixing cosmetic issues (cf. compiler warnings) leads to more and > more noise until real issues are just drowned in the noise; the only > way to achieve excellence (in terms of quality) is discipline in > adhering to rules and standards obsessively. Does that noise distract us from fixing what really needs fixing? It seems to me that for example migrating ebuilds to newer eclasses is much more important than to fix something that's just cosmetic. But it appears that fixing cosmetic issues is easier and more fun to do... "Kill it with fire!" > If there are (too) many false positives we should add proper > annotations to silence repoman ... Are there other false positives than the multi-line readme eclass ones? > > 3. Can USE flags actually be removed from stable ebuilds? >=20 > Usually removing stable ebuilds makes useflags "disappear", rarely > does masking stuff (e.g. old cups) lead to the disappearance of > useflags as they would now be broken The question is about the removal of an USE flag, not the removal of an ebuild; it rather addresses changing the ebuild to remove the USE flag, to address the context of this thread. > > 4. ... >=20 > Do we need to discuss this? >=20 > No. It's an amazing waste of time, almost as if we had no real > problems to focus on. Maybe, maybe not; some parts of it can yield bike-shedding, but other parts of it can definitely be useful to talk about. Eventually we will need to discuss as a QA team to focus on getting the harder stuff done; because well, just shooting at the low hanging fruit and taking the easy way out and only coming together after "something happened" isn't the way that works well. This thread is a good demonstration of that... > > Because this can yield quite some bike-shedding; the alternative > > "out of the box thinking" package.use.mask solution satisfies both > > parties, which renders that discussion unnecessary. Nobody has > > objected this. >=20 > That is a "fix" specific to this package alone, in the general case it > is not valid. You either want to keep the USE flag description or you don't. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/Cw7Ybmj8T08oGT=Ftxp2DbK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJSvxR7AAoJEJWyH81tNOV9s/UIAL62w3t4U2F/b6H81t/ZiGxg y07PBf0LXPBALqfcHZOu6B/909B6UJyH2yILL/U80UjCGZXelmVtRFMk1qXjAHUE yiCahX7b+u2QWJlnDHwa0czvODHUr2X2rWYRvDVE8mkwByka0Js9QtJin6nENwEA nRvpJ3pHQWYAJ/DevpuzbobVX5Wqy1l52issPljgIxQ+6g4Bytl0ham2nNNg/udL nvC3AVWj/K3VNLCjJAaiauTj3AHoqZIxjrvhPURjPiA4A/j6LWPzf/ZQ2Ay4VJyX e3yTY4HOox7umAvk88DbNVintDPn2V8vNQSRaZv1kwfK+eYyJawTSDac4htQkmU= =C50X -----END PGP SIGNATURE----- --Sig_/Cw7Ybmj8T08oGT=Ftxp2DbK--