Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] QA Team's role
Date: Tue, 28 Feb 2006 22:06:48
In Reply to: Re: [gentoo-dev] [RFC] QA Team's role by Mike Frysinger
1 Mike Frysinger wrote:
2 > On Tuesday 28 February 2006 16:02, Jakub Moc wrote:
3 >
4 >>28.2.2006, 21:39:43, Mike Frysinger wrote:
5 >>
6 >>>whats your point ? if an ebuild author wants to control the SLOT, then
7 >>>they should be able to without having an invalid warning issued on the
8 >>>subject
9 >>>
10 >>>considering the nature of the warning, it should be trivial to make it
11 >>>into a proper QA check by having the class see where files were installed
12 >>>and then warn/abort if certain conditions are met
13 >>>
14 >>>there's no reason for the user to see this crap
15 >>
16 >>Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
17 >>eclass inherited illegally crap and a couple of others - this isn't going
18 >>anywhere.
19 >
20 >
21 > unrelated ... that is a portage limitation that has deeper work going on
22 > around it to resolve the issue properly ... this is an eclass limitation that
23 > can be resolved now
24 >
25 >
26 >>You are trying to solve something that noone ever complained about. Why not
27 >>rather solve stuff like ebuilds that depend unconditionally on arts, but
28 >>because they inherit kde eclass they get bogus arts use flag from the
29 >>eclass. This is an issue that's truly confusing and that people are filing
30 >>bugs about. There's the difference between doing something useful and
31 >>wasting time on an artificially invented issue.
32 >
33 >
34 > right, so from now on people shouldnt bother fixing issues until a bug is
35 > filed, that way we know someone actually cares enough to have the issue
36 > resolved
37 >
38 > today's lesson: proactive QA is frowned upon, it's only a bug when a user
39 > files a report at
40 > -mike
42 Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see
43 bugs filed in almost all circumstances. If QA and the maintainer can
44 fix stuff without bugs, thats cool, especially for trivial matters. If
45 QA and the developer aren't getting along on a specific issue then there
46 is no reason NOT to have a bug open.
48 Otherwise you get circumstances that were also discussed, such as "I
49 told the maintainer in person over a year ago..." which may in fact be
50 true, but people forget things and make mistakes and now you have
51 nothing to point at for proof of inactivity except a vague statement.
52 Better to cover your rear and be able to point to a year old bug with a
53 solution attached, and be like "look there is a bug and a fix and no one
54 did jack squat." Essentially you have a case for any sane developer to
55 agree with.


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] [RFC] QA Team's role Mike Frysinger <vapier@g.o>