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 1MACaS-0007ng-OT for garchives@archives.gentoo.org; Sat, 30 May 2009 00:38:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B76EEE02B5; Sat, 30 May 2009 00:38:11 +0000 (UTC) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.154]) by pigeon.gentoo.org (Postfix) with ESMTP id 94618E02B5 for ; Sat, 30 May 2009 00:38:11 +0000 (UTC) Received: by yx-out-1718.google.com with SMTP id 36so22983961yxh.46 for ; Fri, 29 May 2009 17:38:11 -0700 (PDT) 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 Sender: antarus@scriptkitty.com Received: by 10.231.38.197 with SMTP id c5mr38870ibe.3.1243643891136; Fri, 29 May 2009 17:38:11 -0700 (PDT) In-Reply-To: <4A1EE2C0.4070002@gentoo.org> References: <20090527210642.6b7b0f21@snowcone> <20090528004518.5a4f91b5@snowcone> <200905280828.13024.patrick@gentoo.org> <20090528191457.21ab4546@snowcone> <4A1EE2C0.4070002@gentoo.org> Date: Fri, 29 May 2009 17:38:11 -0700 X-Google-Sender-Auth: 76579d948a9cc5f1 Message-ID: Subject: Re: [gentoo-dev] How not to discuss From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 1f477f24-a680-41cf-acff-17d19e205333 X-Archives-Hash: 6bc289345c2cfa203220cd1c4734fd36 On Thu, May 28, 2009 at 12:15 PM, Joe Peterson wrote: > Alec Warner wrote: >>> No, it's entirely objective. GLEP 55 clearly shows how the filename >>> based options are objectively better than anything else. >> >> But the decision will not be based entirely on objective merits >> (although I will concede that EAPI in filename is the 'best' technical >> choice). > > (Jeez, I hate to add another to this thread, but this way of defining > 'technical' bothers me) Lets agree to disagree on the definition of "technical" then and instead agree that putting EAPI in the filename is a bad design decision ("technicalness" aside) and then have a beer! > > Along the lines of what Roy so eloquently expressed, I think it's > important that we do not divorce *design* from *technical*. The > decision of where to place the EAPI is a design issue, and many of us > here clearly believe that it is *not* good design to put this kind of > metadata in the filename. Therefore, the statement that it is the > 'best' technical choice is not objectively true. > > Technical issues of performance and efficiency can be addressed when > proper design has been done beforehand. Part of the purpose of the > implementation (after proper design is in place) is to address > performance and other related issues. And part of the design is how we > define the *interface*. The filename is clearly part of the interface. > It is part of how devs (and users) interact with portage when writing > ebuilds. Much of the argument for EAPI in the filename has been > motivated by a perceived implementation benefit of speed, as if there > were no other solutions (which is naive). As Roy suggested, if all > engineering decisions were based purely on pragmatic "ease of > implementation" factors, we'd have a lot of ugly designs/interfaces out > there. > > It may be easy (although incorrect) to dismiss elegance/design/interface > issues as "non-technical", but I maintain they actually *are* technical > matters of great importance. I've been an engineer for over 20 years, > and I have seen the pitfalls of taking the quick-and-dirty approach just > to slap a new feature into a software app. I've seen how such hasty > design mistakes can cause great pain and regret for a long time after. > Let's get the design right, first. For what it's worth, GLEP 55 does > now provide an option (#3: Easily fetchable EAPI inside the ebuild and > one-time extension change) that demonstrates good design. > > -Joe > >