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 1FE1XP-0006Ww-9k for garchives@archives.gentoo.org; Tue, 28 Feb 2006 09:52:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1S9m8XO011820; Tue, 28 Feb 2006 09:48:08 GMT Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1S9iQQH005736 for ; Tue, 28 Feb 2006 09:44:27 GMT Received: (qmail 27875 invoked from network); 27 Feb 2006 22:39:04 -0000 Received: from unknown (HELO server.grantgoodyear.org) (s?robertson@sbcglobal.net@67.67.81.246 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 27 Feb 2006 22:39:04 -0000 Received: from [64.76.20.1] (dst [192.168.1.3]) (authenticated bits=0) by server.grantgoodyear.org (8.13.4/8.13.4) with ESMTP id k1RMd2Xu009505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 16:39:03 -0600 Message-ID: <44037F83.4080006@gentoo.org> Date: Mon, 27 Feb 2006 16:38:59 -0600 From: Grant Goodyear User-Agent: Thunderbird 1.5 (Windows/20051201) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role 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> <44036974.9070200@gentoo.org> <44036C8D.8030209@gentoo.org> In-Reply-To: <44036C8D.8030209@gentoo.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8D791DAC7BC43B943D515D15" X-Archives-Salt: 5d12bf5b-f915-4acc-9f3e-c47ec7720b51 X-Archives-Hash: e7ccbde0d6876a43a846404922287f33 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8D791DAC7BC43B943D515D15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen P. Becker wrote: > Grant Goodyear wrote: >> Ciaran McCreesh wrote: >>> My point is that that's a nasty QA bug that's relying upon input from= >>> Stuart to be fixed. Whilst that one's still alive, I'm not going to g= o >>> around filing more similar "breaks non-interactively" bugs because th= e >>> discussion will just get repeated over and over. >> Huh? I just read through the bug, and it actually appears to be >> resolved pending Chris' testing w/ the needed USE flags added to the >> various profiles. I'll admit that the fix is inelegant, but I'm missi= ng >> where it's waiting upon Stuart for additional info. Am I missing some= thing? >=20 > Yes, you are missing that the bug really isn't fixed. There are still > USE combinations which would be otherwise perfectly valid, but which > cause php to fail to emerge, thus reaking non-interactivity and forcing= > people to (ab)use /etc/portage/package.use to get things working proper= ly. Well, I did say that it was an inelegant fix.... In any event, I appreciate your response about php brokenness (I'll come back to this below), but does this php brokenness require additional info from Stuart to fix? Let me try breaking things down a bit to see if I can understand the various specific problems: 0. Stuart and Ciaranm (and Jakub and Ciaranm) don't like each other very much. *Shrug* That's not really a problem, it just means that one needs hip-waders to get through all of the muck. No big deal; that's part of being a dev with a really large project. 1. A fresh Gentoo install w/ default USE flags will fail to compile dev-lang/php. That one is being "solved" by adding some additional USE flags to the default profile. The claim from the php team is that the correct fix is a version of portage with USE-based dependencies. The QA folks would prefer to see the php ebuild implement a set of sane defaults to prevent breakages, instead, if I understand correctly, which in practice would mean that the ebuild would detect whether or not deps were built with the correct USE flags, and work around any "broken" deps in the ebuild. (I must be missing something, since the latter strikes me as notably _bad_, since it would mean that two people with identical USE flags would get different outcomes depending on how their dependencies are built.) 2. There are a variety of otherwise-valid USE-flag combinations that will cause php to fail to build (or be otherwise unusable). That's hardly surprising, since dev-lang/php has ~100 USE flags, which means ~2**100 (~10**30) possible USE-flag combinations. Let's see, there are roughly pi*10**7 seconds per year, so if we could test one build of php per second it would only take considerably longer than the lifetime of the universe to test all of the possible combinations. Clearly QA of the current ebuild has to be rather illusory. Do we have a bug open about this? Are there any reasonable suggestions on how to fix it? I do realize that the problem is complicated by the fact that people really do use fairly esoteric php builds on production machines. That said, the current situation really is a nightmare! 3. There are a number of people (not just ciaranm) who consider the webapp idea to be brilliant in concept, but horribly flawed in its execution. (I'm personally fairly agnostic, although the one time that I had to create a webapp-enabled ebuild I found the process to be incredibly confusing. I just assumed that with great flexibility comes great pain.) However, I've never known precisely why people feel that way, and I can't find any bugs about it, so perhaps we could have a real debate about this issue? I don't think that bug #120088 is it. -g2boojum- --------------enig8D791DAC7BC43B943D515D15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEA3+GptxxUuD2W3YRAkx2AJ0c4Jd1B3hR+OVL9TZQYOPBtHh51QCeNffm Xx2q63AUoXKK4l7EESf54es= =CyGX -----END PGP SIGNATURE----- --------------enig8D791DAC7BC43B943D515D15-- -- gentoo-dev@gentoo.org mailing list