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 <[EMAIL PROTECTED]>: > > >> 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. > > * 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 he's operated as the scary guy who didn't need a team to spank your ass anyways. (that's a joke about him, not the QA team also). pcheck btw, not pquery (former does quality checks, latter is for metadata lookup). And you claim you can recommend to people which 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 what the QA _team_ was up to; thus would try to address that instead of pointing out non-qa team folk do things. Simple example- I still do a bit of QA, doesn't mean it's even remotely quantifiable as QA team work (which is what he was asking) :) Don't particularly want to get sucked into yet another "QA team are lazy slackers" discussion, just pointing out bits above. Advice wise, 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 paludis; portage isn't affected since it prefers to try pulling the metadata from $PORTDIR; reasoning is that way screw ups in the metadata that are now locked in the vdb can be worked around via it. You can trigger the same issue in portage via wiping pretty much everything in PORTDIR (switching the tree, or just a literal rm of everything but profiles crap), but that's fairly corner case. Don't much like the behavior myself, but updates/* would need expansion to address the (massively long term) reasoning for portages behavior. Upshot, running from vdb only instead of the dual lookup would speed up portages resolution via less IO/parsing... Either way, the kde/qt issue was known from the get go- since slot deps weren't available when they started down this path, they should have used new style virtuals instead. Yes it's ugly, backwards compatibility usually isn't utterly pretty- upshot of it however is that the upgrade node is just a new style virtual, no real cost for the operation. Breaking EAPI=0 via pushing slot deps in isn't much of an option in my opinion; usual "needs to have been on release media for at least 6 months" would apply here at the very least. The problem is that 2.1.2 is the first portage version to have slot deps- that is a fairly recent stabling, so there still would be a good chunk of time to wait *if* the daft old method of just shoving stuff in and watching things break was took. Meanwhile, worth remembering during the interim while slot deps aren't usable, new style virtual does address it (even if it's a gross trick) :) ~harring
pgpSqqRDjEheH.pgp
Description: PGP signature
