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 1FECV1-0000al-OU for garchives@archives.gentoo.org; Tue, 28 Feb 2006 21:35:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1SLWmYW017759; Tue, 28 Feb 2006 21:32:48 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 k1SLUVgb031967 for ; Tue, 28 Feb 2006 21:30:32 GMT Received: from localhost ([127.0.0.1] helo=home.wh0rd.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1FECR7-00037W-43 for gentoo-dev@lists.gentoo.org; Tue, 28 Feb 2006 21:31:13 +0000 Received: (qmail 24779 invoked from network); 28 Feb 2006 16:27:43 -0500 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 28 Feb 2006 16:27:43 -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 16:31:37 -0500 User-Agent: KMail/1.9.1 References: <20060227213321.7ee405ec@snowdrop.home> <200602281539.43661.vapier@gentoo.org> <905929917.20060228220239@gentoo.org> In-Reply-To: <905929917.20060228220239@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: <200602281631.37594.vapier@gentoo.org> X-Archives-Salt: 40f72a8a-6a0a-4556-84d7-42866d775adf X-Archives-Hash: 8a495b5e117bf97e94bec4ff5ab2f3c4 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 -mike -- gentoo-dev@gentoo.org mailing list