From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FEE23-0001dx-2q for garchives@archives.gentoo.org; Tue, 28 Feb 2006 23:13:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1SNAhIP027788; Tue, 28 Feb 2006 23:10:43 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1SN78s3001354 for ; Tue, 28 Feb 2006 23:07:08 GMT Received: from localhost ([127.0.0.1] helo=home.wh0rd.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1FEDwW-0004dE-NN for gentoo-dev@lists.gentoo.org; Tue, 28 Feb 2006 23:07:44 +0000 Received: (qmail 22717 invoked from network); 28 Feb 2006 18:04:14 -0500 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 28 Feb 2006 18:04:14 -0500 From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role Date: Tue, 28 Feb 2006 18:08:09 -0500 User-Agent: KMail/1.9.1 References: <20060227213321.7ee405ec@snowdrop.home> <200602281631.37594.vapier@gentoo.org> <4404C786.9020000@gentoo.org> In-Reply-To: <4404C786.9020000@gentoo.org> GEOMAN: IS A RETARD Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602281808.10068.vapier@gentoo.org> X-Archives-Salt: 4141bc87-b91f-4184-a70b-be42c828c6ea X-Archives-Hash: e54c28339ae5a496fd159ff023131485 On Tuesday 28 February 2006 16:58, Alec Warner wrote: > Mike Frysinger wrote: > > On Tuesday 28 February 2006 16:02, Jakub Moc wrote: > >>28.2.2006, 21:39:43, Mike Frysinger wrote: > >>>whats your point ? if an ebuild author wants to control the SLOT, then > >>>they should be able to without having an invalid warning issued on the > >>>subject > >>> > >>>considering the nature of the warning, it should be trivial to make it > >>>into a proper QA check by having the class see where files were > >>> installed and then warn/abort if certain conditions are met > >>> > >>>there's no reason for the user to see this crap > >> > >>Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, > >>eclass inherited illegally crap and a couple of others - this isn't going > >>anywhere. > > > > unrelated ... that is a portage limitation that has deeper work going on > > around it to resolve the issue properly ... this is an eclass limitation > > that can be resolved now > > > >>You are trying to solve something that noone ever complained about. Why > >> not rather solve stuff like ebuilds that depend unconditionally on arts, > >> but because they inherit kde eclass they get bogus arts use flag from > >> the eclass. This is an issue that's truly confusing and that people are > >> filing bugs about. There's the difference between doing something useful > >> and wasting time on an artificially invented issue. > > > > right, so from now on people shouldnt bother fixing issues until a bug is > > filed, that way we know someone actually cares enough to have the issue > > resolved > > > > today's lesson: proactive QA is frowned upon, it's only a bug when a user > > files a report at bugs.gentoo.org > > Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see > bugs filed in almost all circumstances. If QA and the maintainer can > fix stuff without bugs, thats cool, especially for trivial matters. If > QA and the developer aren't getting along on a specific issue then there > is no reason NOT to have a bug open. > > Otherwise you get circumstances that were also discussed, such as "I > told the maintainer in person over a year ago..." which may in fact be > true, but people forget things and make mistakes and now you have > nothing to point at for proof of inactivity except a vague statement. > Better to cover your rear and be able to point to a year old bug with a > solution attached, and be like "look there is a bug and a fix and no one > did jack squat." Essentially you have a case for any sane developer to > agree with. dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was addressing the incorrect idea that it isnt a valid QA issue unless a user experiences it and complains via bugzilla -mike -- gentoo-dev@gentoo.org mailing list