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.62) (envelope-from ) id 1HZZV8-0000kz-Rf for garchives@archives.gentoo.org; Thu, 05 Apr 2007 21:28:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l35LQfAt019347; Thu, 5 Apr 2007 21:26:41 GMT Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [204.127.225.93]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l35LO5rD016079 for ; Thu, 5 Apr 2007 21:24:06 GMT Received: from seldon (c-67-171-130-60.hsd1.or.comcast.net[67.171.130.60]) by comcast.net (alnrmhc13) with SMTP id <20070405212403b1300jlcnqe>; Thu, 5 Apr 2007 21:24:03 +0000 Date: Thu, 5 Apr 2007 14:24:06 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April Message-ID: <20070405212406.GA13118@seldon> References: <20070401092940.1B4C26441E@smtp.gentoo.org> <20070405201217.TA36bc4.tv@veller.net> <46153DF7.5060801@gentoo.org> <200704052240.56083.kugelfang@gentoo.org> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <200704052240.56083.kugelfang@gentoo.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 4cae784b-7d19-4772-a9b0-5a0fb7772a3f X-Archives-Hash: 3a118ef35e58b0afd9efe66ce9a27111 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote: > Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: > > Torsten Veller wrote: > > > * Mike Doty : > > >> apparent decline of QA in our packages. > > > > > > Why do you want this to be a council topic if it wasn't even a > > > topic here or on gentoo-qa@ ? > > > > Because our QA sucks and noone is doing a damn thing about it. > I disagree. The QA team is doing a lot of work. >=20 > * Mr_Bones still runs QA checks on the whole tree daily and people are > still scared if he pops up and pastes his repoman/pquery output. Last I knew, bones wasn't part of the QA team anymore. Historically=20 he's operated as the scary guy who didn't need a team to spank your=20 ass anyways. (that's a joke about him, not the QA team also). pcheck btw, not pquery (former does quality checks, latter is for=20 metadata lookup). And you claim you can recommend to people which=20 tools to use :-) > * You don't need to be a member of the "QA project/team" to do QA. I say > this here, but i think that should be self-evident. Agreed, although worth keeping in mind the question specifically was=20 what the QA _team_ was up to; thus would try to address that instead=20 of pointing out non-qa team folk do things. Simple example- I still=20 do a bit of QA, doesn't mean it's even remotely quantifiable as QA=20 team work (which is what he was asking) :) Don't particularly want to get sucked into yet another "QA team are=20 lazy slackers" discussion, just pointing out bits above. Advice wise,=20 take it or leave. Meanwhile onto the real meat of the email... > * There is at least one outstanding QA issue that i know of which is > related to Portage and can't be fixed w/o slot deps properly. > Read: KDE's problems with ranged deps and the way it currently > breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs. Elaborating a bit, this actually is only a problem for pkgcore and=20 paludis; portage isn't affected since it prefers to try pulling the metadata from $PORTDIR; reasoning is that way screw ups in the=20 metadata that are now locked in the vdb can be worked around via it. =20 You can trigger the same issue in portage via wiping pretty much=20 everything in PORTDIR (switching the tree, or just a literal rm of=20 everything but profiles crap), but that's fairly corner case. Don't much like the behavior myself, but updates/* would need=20 expansion to address the (massively long term) reasoning for portages=20 behavior. Upshot, running from vdb only instead of the dual lookup=20 would speed up portages resolution via less IO/parsing... Either way, the kde/qt issue was known from the get go- since slot=20 deps weren't available when they started down this path, they should=20 have used new style virtuals instead. Yes it's ugly, backwards=20 compatibility usually isn't utterly pretty- upshot of it however is=20 that the upgrade node is just a new style virtual, no real cost for=20 the operation. Breaking EAPI=3D0 via pushing slot deps in isn't much of an option in=20 my opinion; usual "needs to have been on release media for at least 6=20 months" would apply here at the very least. The problem is that 2.1.2=20 is the first portage version to have slot deps- that is a fairly=20 recent stabling, so there still would be a good chunk of time to wait=20 *if* the daft old method of just shoving stuff in and watching things=20 break was took. Meanwhile, worth remembering during the interim while slot deps aren't=20 usable, new style virtual does address it (even if it's a gross trick)=20 :) ~harring --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGFWj2siLx3HvNzgcRAm76AKCD+VyU5DFRXXzXDSOrZPNMS2bqbwCg0IFz qFJoG/hGy1nBIkxCZbOihC4= =8mMh -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- -- gentoo-dev@gentoo.org mailing list