From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FE6d9-00081G-Rn for garchives@archives.gentoo.org; Tue, 28 Feb 2006 15:19:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1SFEgNe012002; Tue, 28 Feb 2006 15:14:42 GMT Received: from smtp.top-hosting.cz (gw.top-hosting.cz [81.0.254.91]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1SF7F0T015052 for ; Tue, 28 Feb 2006 15:07:15 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.top-hosting.cz (Postfix) with ESMTP id 2CC0BAA91CF for ; Tue, 28 Feb 2006 16:08:17 +0100 (CET) Received: from smtp.top-hosting.cz ([127.0.0.1]) by localhost (smtp.top-hosting.cz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31069-05-4 for ; Tue, 28 Feb 2006 16:08:08 +0100 (CET) Received: from NOTORCOMP (21.217.broadband4.iol.cz [85.71.217.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.top-hosting.cz (Postfix) with ESMTP id DDC42A46CC8 for ; Tue, 28 Feb 2006 16:08:07 +0100 (CET) Date: Tue, 28 Feb 2006 16:08:05 +0100 From: Jakub Moc X-Priority: 3 (Normal) Message-ID: <1507322031.20060228160805@gentoo.org> To: Ciaran McCreesh Subject: Re[2]: [gentoo-dev] [RFC] QA Team's role In-Reply-To: <20060228143940.23149665@snowdrop.home> References: <20060226222217.GB17257@aerie.halcy0n.com> <1140997703.12229.166.camel@demandred.gnqs.org> <20060227003413.GE17257@aerie.halcy0n.com> <20060227170834.075e9388@snowdrop.home> <1141071970.804.19.camel@demandred.gnqs.org> <20060227203709.2a7bff47@snowdrop.home> <20060227204530.GO1516@toucan.gentoo.org> <20060227205445.057a91d9@snowdrop.home> <1141074742.826.35.camel@demandred.gnqs.org> <20060227213239.5cf14f0d@snowdrop.home> <1741768966.20060228104913@gentoo.org> <20060228143940.23149665@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------7216BA4432BE3A" X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at top-hosting.cz X-Spam-Status: No, score=-1.984 tagged_above=-999 required=6 tests=[AWL=0.615, BAYES_00=-2.599] X-Spam-Score: -1.984 X-Spam-Level: X-Archives-Salt: a1455bd6-0a66-47ab-a970-ed6f11623c86 X-Archives-Hash: ce8fae4528c2e6f9b501f3aa3545d6ad ------------7216BA4432BE3A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =0D=0A28.2.2006, 15:39:40, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc wrote: > | No, that's not a policy document, ebuild policy is documented here: > | > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=3Dprinta= ble&part=3D3&chap=3D1 > No, the whole thing is policy. No, it isn't. And silently sticking parts of unofficial gentoo devmanual into official Gentoo docs, and then silently turning them into a "policy" enforced under QA disguise is a bad very practice, and pretending that this has been in the mentioned _howto_ (not policy) for a long time as just plain silly. Since you haven't answered the question in one of my previous emails at all, let me ask again: When and where has been the following change discussed and who approved that? http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handboo= k/hb-guide-ebuild.xml?r1=3D1.25&r2=3D1.26&root=3Dgentoo > | Moreover, the cited howto is wrong, since it will break built_with_use > | checks > No, that's a separate issue. No, it isn't. If you want something to have as a policy, it needs to be error-free, reasonably applicable and not doing more harm than if it isn't applied at all. And implementing such stuff requires a proper discussion, considering the consequences and some sort of consent among affected developers. (Also, that howto example is less than fortunate/clear, like some user noted in Bug 124401). > | The howto also doesn't apply to cases like > | recode vs. mysql, because that's a completely different > | functionality, you can't exactly choose which one is better on behalf > | of the user. > No, it does apply. No, it doesn't, you can't reasonably favour one of two completely different functionalities based on some automagic assumption/developer discretion. That doesn't benefit users in any way and just produces unexpected results (hey, I explicitely enabled "recode" use flag and php compiled without, the ebuild is broken, fix0r it!) > | So, to sum it up - you can't make up for portage's lack of features by > | inventing a policy that doesn't work. Once again - until portage can > | handle USE-based dependencies and until portage can handle > | conflicting use flags, there's nothing that could be done here. > Until Portage can handle conflicting USE flags, one should take the > policy-mandated solution that has been sufficient for everyone else for > four years or more. Sure, it's not perfect, but it's a hell of a lot > better than repeatedly exploding in the user's face midway through an > install. No, noone should enforce a policy that - doesn't exist (see above) - hasn't been discussed properly and approved (see above) - it's consequences haven't been considered wrt whether its benefits overweight the negatives and whether is useful at all. --=20 Best regards, Jakub Moc mailto:jakub@gentoo.org GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=3Dget&search=3D0= xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) ------------7216BA4432BE3A Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEBGdUhxfV/c66PZ4RAvS7AJ9kVi5u+/rKGSTyGmVsWiCzmS3+GQCfQZCa oSUFJ/6RoH0nKN1x/uUjafM= =sgd7 -----END PGP MESSAGE----- ------------7216BA4432BE3A-- -- gentoo-dev@gentoo.org mailing list