1 |
Am Donnerstag, 5. April 2007 23:24 schrieb Brian Harring: |
2 |
> On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote: |
3 |
> > Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty: |
4 |
> > > Torsten Veller wrote: |
5 |
> > > > * Mike Doty <kingtaco@g.o>: |
6 |
> > > >> apparent decline of QA in our packages. |
7 |
> > > > |
8 |
> > > > Why do you want this to be a council topic if it wasn't even a |
9 |
> > > > topic here or on gentoo-qa@ ? |
10 |
> > > |
11 |
> > > Because our QA sucks and noone is doing a damn thing about it. |
12 |
> > |
13 |
> > I disagree. The QA team is doing a lot of work. |
14 |
> > |
15 |
> > * Mr_Bones still runs QA checks on the whole tree daily and people |
16 |
> > are still scared if he pops up and pastes his repoman/pquery |
17 |
> > output. |
18 |
> |
19 |
> Last I knew, bones wasn't part of the QA team anymore. Historically |
20 |
See my comments regard QA team membership and doing QA work. Having a QA |
21 |
team doesn't magically improve the quality of the tree. |
22 |
|
23 |
> he's operated as the scary guy who didn't need a team to spank your |
24 |
> ass anyways. (that's a joke about him, not the QA team also). |
25 |
> |
26 |
> pcheck btw, not pquery (former does quality checks, latter is for |
27 |
> metadata lookup). And you claim you can recommend to people which |
28 |
> tools to use :-) |
29 |
I never claimed i'd recommend your set of tools. This doesn't mean they |
30 |
are inferior, it's just that i can't recommend what i don't use and |
31 |
know. |
32 |
|
33 |
> > * You don't need to be a member of the "QA project/team" to do QA. |
34 |
> > I say this here, but i think that should be self-evident. |
35 |
> |
36 |
> Agreed, although worth keeping in mind the question specifically was |
37 |
> what the QA _team_ was up to; thus would try to address that instead |
38 |
> of pointing out non-qa team folk do things. Simple example- I still |
39 |
> do a bit of QA, doesn't mean it's even remotely quantifiable as QA |
40 |
> team work (which is what he was asking) :) |
41 |
> |
42 |
> Don't particularly want to get sucked into yet another "QA team are |
43 |
> lazy slackers" discussion, just pointing out bits above. Advice |
44 |
> wise, take it or leave. |
45 |
Heh... |
46 |
|
47 |
> Meanwhile onto the real meat of the email... |
48 |
> |
49 |
> > * There is at least one outstanding QA issue that i know of which |
50 |
> > is related to Portage and can't be fixed w/o slot deps properly. |
51 |
> > Read: KDE's problems with ranged deps and the way it currently |
52 |
> > breaks the vdb's RDEPEND entries, especially regarding qt and |
53 |
> > kdelibs. |
54 |
> |
55 |
> Elaborating a bit, this actually is only a problem for pkgcore and |
56 |
> paludis; portage isn't affected since it prefers to try pulling the |
57 |
> metadata from $PORTDIR; reasoning is that way screw ups in the |
58 |
> metadata that are now locked in the vdb can be worked around via it. |
59 |
AFAIK zmedico spoke about moving portage to use vdb metadata instead. |
60 |
Before this could happen we needed a fix for it. |
61 |
|
62 |
> You can trigger the same issue in portage via wiping pretty much |
63 |
> everything in PORTDIR (switching the tree, or just a literal rm of |
64 |
> everything but profiles crap), but that's fairly corner case. |
65 |
> |
66 |
> Don't much like the behavior myself, but updates/* would need |
67 |
> expansion to address the (massively long term) reasoning for portages |
68 |
> behavior. Upshot, running from vdb only instead of the dual lookup |
69 |
> would speed up portages resolution via less IO/parsing... |
70 |
> |
71 |
> Either way, the kde/qt issue was known from the get go- since slot |
72 |
> deps weren't available when they started down this path, they should |
73 |
> have used new style virtuals instead. Yes it's ugly, backwards |
74 |
> compatibility usually isn't utterly pretty- upshot of it however is |
75 |
> that the upgrade node is just a new style virtual, no real cost for |
76 |
> the operation. |
77 |
> |
78 |
> Breaking EAPI=0 via pushing slot deps in isn't much of an option in |
79 |
> my opinion; usual "needs to have been on release media for at least 6 |
80 |
We can push for an EAPI=1 == (EAPI=0 + slot deps)... |
81 |
|
82 |
> months" would apply here at the very least. The problem is that |
83 |
> 2.1.2 is the first portage version to have slot deps- that is a |
84 |
> fairly recent stabling, so there still would be a good chunk of time |
85 |
> to wait *if* the daft old method of just shoving stuff in and |
86 |
> watching things break was took. |
87 |
What breakage specifically? Portage versions that don't support EAPI? |
88 |
> |
89 |
> Meanwhile, worth remembering during the interim while slot deps |
90 |
> aren't usable, new style virtual does address it (even if it's a |
91 |
> gross trick) |
92 |
I prefer we solve this problem instead of hacking around it once more. |
93 |
|
94 |
Danny |
95 |
-- |
96 |
Danny van Dyk <kugelfang@g.o> |
97 |
Gentoo/AMD64 Project, Gentoo Scientific Project |
98 |
-- |
99 |
gentoo-dev@g.o mailing list |