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 1FELws-0002V2-M1 for garchives@archives.gentoo.org; Wed, 01 Mar 2006 07:40:39 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k217dhqe031481; Wed, 1 Mar 2006 07:39:43 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 k217br3r001530 for ; Wed, 1 Mar 2006 07:37:53 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.top-hosting.cz (Postfix) with ESMTP id B260851E91A for ; Wed, 1 Mar 2006 08:38:02 +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 28809-03 for ; Wed, 1 Mar 2006 08:37:49 +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 C11F4D39C for ; Wed, 1 Mar 2006 08:37:48 +0100 (CET) Date: Wed, 1 Mar 2006 08:37:47 +0100 From: Jakub Moc X-Priority: 3 (Normal) Message-ID: <1908167286.20060301083747@gentoo.org> To: Ciaran McCreesh Subject: Re[2]: [gentoo-dev] [RFC] QA Team's role In-Reply-To: <20060228152910.7786271e@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> <1507322031.20060228160805@gentoo.org> <20060228152910.7786271e@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="----------11F1A41462EC8D75D" X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at top-hosting.cz X-Spam-Status: No, score=-2.017 tagged_above=-999 required=6 tests=[AWL=0.582, BAYES_00=-2.599] X-Spam-Score: -2.017 X-Spam-Level: X-Archives-Salt: ca5cfba8-79de-42b0-ba59-a1f0270a6ef9 X-Archives-Hash: e1d53ff0a26e5c29c5819cdedd1f6020 ------------11F1A41462EC8D75D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =0D=0A28.2.2006, 16:29:10, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc wrote: > | 28.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=3Dpri= ntable&part=3D3&chap=3D1 > |=20 | >> No, the whole thing is policy. > |=20 > | No, it isn't. > 'Fraid it is. Everything in the devrel handbook that isn't explicitly > marked as a guideline is policy. Sorry, such procedure is not acceptable until you change the whole metastructure of the project so that a bunch of people is allowed to dictate to others whatever they think is fit. (Another question is how many people will want to work on such project.) Until that's done, things should be discussed and some form of consent reached. > | 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/handb= ook/hb-guide-ebuild.xml?r1=3D1.25&r2=3D1.26&root=3Dgentoo > Wouldn't know. That was nothing to do with me. I just wrote the > original text (or actually, that might not even have been me). It > finding its way into the policy docs was devrel's doing. Again, see above. | >> | Moreover, the cited howto is wrong, since it will break | >> | built_with_use checks > |=20 | >> No, that's a separate issue. > |=20 > | 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). > built_with_use isn't a question of conflicting USE flags. It's a > separate question of dependency resolution, and in this situation it > *can't* be solved using the method that's been standard for four years > or more. Sure it is. You can't silently enable/disable some feature if other ebuilds are checking for that feature using those very use flags that you have ignored/overriden/bypassed. Such checks are useless then and more stuff gets broken than gets fixed. > | 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!) > By all means warn the user. There's nothing in policy disallowing that. That doesn't work, it breaks other things as explained above. Please, don't use a hammer where watchmaker's screwdriver is a proper tool, otherwise you'll severely damage the whole thing. One minute spent on tweaking use flags is much less important than a bunch of useful features missing just because you've hammered the whole stuff together. > | No, noone should enforce a policy that > |=20 > | - doesn't exist (see above) > The whole devrel handbook is policy, except where otherwise noted. See > Mike's reply. Then any significant change there requires a sane procedure. --=20 jakub ------------11F1A41462EC8D75D Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEBU9LhxfV/c66PZ4RAruGAJ4spWHnCPYKTH7+PpTZx1Gk0c6DkQCdH6VR VIwZSkBe7aUJ0OZYOsGQC7w= =F0cR -----END PGP MESSAGE----- ------------11F1A41462EC8D75D-- -- gentoo-dev@gentoo.org mailing list