Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April

[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 <kingtaco@g.o>:
> > >> 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