From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N7T4G-0007oo-7M for garchives@archives.gentoo.org; Mon, 09 Nov 2009 12:09:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 50A21E0B1B; Mon, 9 Nov 2009 12:09:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0AAC9E0B1B for ; Mon, 9 Nov 2009 12:09:53 +0000 (UTC) Received: from [192.168.1.35] (unknown [77.246.104.171]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 94234678E9 for ; Mon, 9 Nov 2009 12:09:51 +0000 (UTC) Subject: Re: [gentoo-dev] QA is unimportant? (was: gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild) From: Peter Volkov To: gentoo-dev@lists.gentoo.org In-Reply-To: <4AF76449.9020203@gentoo.org> References: <200911081910.35133.patrick@gentoo.org> <200911081324.47874.vapier@gentoo.org> <200911082008.35448.patrick@gentoo.org> <20091108192723.GB31601@aerie.halcy0n.com> <4AF76449.9020203@gentoo.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 09 Nov 2009 15:08:52 +0300 Message-ID: <1257768532.20446.1350.camel@tablet> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 89067c16-a6e7-4545-b857-735416526a65 X-Archives-Hash: 76ceb58eb4b5c5df5358d22634178a0b =D0=92 =D0=9F=D0=BD=D0=B4, 09/11/2009 =D0=B2 01:37 +0100, Vlastimil Babka= =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > I totally agree. And I must say it started with the very first mail of=20 > pva. Accusing of not knowing quizzes was totally uncalled for. If you know how to do thing properly what are the reasons avoid doing that? All I heard here is laziness and I don't think this is acceptable. > As patrick said, the SRC_URI thing was simply forgot to be polished aft= er=20 > testing, and the dobin thing he didn't even touch. Who remembers what=20 > everything should have || die or not from the top of his head and spots= =20 > it immediatelly? Quizzes are the basic knowledge required to work with tree. Do you state that it's impossible to remember answers on quizzes? Should we drop quizzes then and let people do whatever they want with the tree? Please, stop this nonsense advocation. > And this offensive tone just provoked adequate reaction Offence was not my intention. I apologize for tone. That said, Patrick insist on mistakes he is well aware about, e.g. take a look at this ebuild: http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/snort/snort-= 2.8.4.1.ebuild?hideattic=3D0&rev=3D1.1&view=3Dmarkup This is user submitted ebuild, without any modifications and with number of QA problems that Patrick commited. I've tried to contact Patrick and Jason (user who did and does snort job) and while Jason fixed everything in next version Patrick avoided to fix even crying things (e.g. missed || die after emake) in the tree for ebuild that was fast stabilized. No offense, but again I have to admit that Patrick forgot an answers on ebuild-quiz questions 3 (b) and 4. And worst thing is that he is not going to fix things he commited to the tree... I hope this explains my tone, but again I apologize for it. > and here we are, useless flame. This thread is not "useless flame". It revealed at least two concerns: 1. Our good non-formal policy "if developer touched anything he becames responsible for that ebuild and should fix issues noticed" is sometimes ignored. We see people reacting: you've noticed - you fix. I think such attitude is unacceptable. Telling somebody that crap was in the previous version of ebuild so I'm not gonna fix it does not make any sense. Things change and developers are supposed to follow changes. This means that since new coding standards were introduced new ebuilds follow them. Even users on Sunrise managed to learn this easy || die thing and I really hope that developers who passed quizzes are capable too. I don't even see how || die is "cosmetics" - it is either redudand (in case of econf) or missed code (in case of make). The first one just introduces more crap around the latter could make ebuild miss build failure. 2. Some developers prefer to do "blind" bumps (just rename .ebuild and check if it builds). This kind of things are possible in case package is used on daily basis and package development was followed. In all other cases if developer touchs new package he is supposed to check it as a "new package", from the very beginning. In case version bump done properly the things I'm asking about will take less then 1% of developer's time: with bump developer is supposed to review modifications of build system, check if seds/patches inside package are still required and check that there are no new deps. At the same time it's really easy remove redudant || die or drop default src_compile { emake || die ; } functions. I'm really surprised to see that people insist that such ebuilds are better then unmaintained: it's really hard to call such "blind" bump as package maintainance but this bump hides unmaintained packages in the tree. Yes, this makes things worse. Well, it looks like the root of this problem is the following statement: "QA is less important then new packages in the tree". I failed to hear any arguments why QA is unimportant so I still believe that QA problem is a problem. --=20 Peter.