Am Donnerstag, 5. April 2007 23:24 schrieb Brian Harring: > 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 See my comments regard QA team membership and doing QA work. Having a QA team doesn't magically improve the quality of the tree.
> 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 :-) I never claimed i'd recommend your set of tools. This doesn't mean they are inferior, it's just that i can't recommend what i don't use and know. > > * 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. Heh... > 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. AFAIK zmedico spoke about moving portage to use vdb metadata instead. Before this could happen we needed a fix for 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 We can push for an EAPI=1 == (EAPI=0 + slot deps)... > 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. What breakage specifically? Portage versions that don't support EAPI? > > 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) I prefer we solve this problem instead of hacking around it once more. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
