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 1M9lSm-0007eA-51 for garchives@archives.gentoo.org; Thu, 28 May 2009 19:40:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6E3C3E045E; Thu, 28 May 2009 19:40:26 +0000 (UTC) Received: from mail-fx0-f219.google.com (mail-fx0-f219.google.com [209.85.220.219]) by pigeon.gentoo.org (Postfix) with ESMTP id 19A57E045E for ; Thu, 28 May 2009 19:40:26 +0000 (UTC) Received: by fxm19 with SMTP id 19so5133851fxm.34 for ; Thu, 28 May 2009 12:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type:content-transfer-encoding; bh=UF4db/phsq4kCysK+BCFRYUGgbIbTZuliSEvBh6BxrQ=; b=I4vU0Q1YLzvJEvn8Ej5Pi5fk+0PcAQvgaD/FVMTJNv6UFua9wbEngb1+jSOhf8md8f LghL0eks18S+nio6liF65EvnFCPGLsWtwfz5gnJpaP7jqhtyYY2o6oM0PMXszBrsQ0Jt 3xmgWPkMMFXn4Lt4s6t02VBs6YWYt2GQApOfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=pbqSJD5EPu8ArYFzVev1CNOkCjGwZUJybVO9kHl8p6/EpGA9tRO04sIm3g7o/hAiXN YXoep6XfQ2zT6QaECs1a8ZKvn8d7r/NnYux65o5ezLrzBXmMDGyuOOlJDKYL1wYHA++T rP+8ieRmVfbjZBa80ejrZ5ahkIldOqWpOAAkY= 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: p.jaroszynski@gmail.com Received: by 10.204.57.67 with SMTP id b3mr1524464bkh.128.1243539625327; Thu, 28 May 2009 12:40:25 -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> From: =?UTF-8?Q?Piotr_Jaroszy=C5=84ski?= Date: Thu, 28 May 2009 21:40:03 +0200 X-Google-Sender-Auth: 1c5bd98cba145dd2 Message-ID: Subject: Re: [gentoo-dev] How not to discuss To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d3b55258-eb86-4de8-a655-9729ac775c83 X-Archives-Hash: 2bc45b3fa03220286c11a9b9b45b0124 2009/5/28 Joe Peterson : > 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) > > Along the lines of what Roy so eloquently expressed, I think it's > important that we do not divorce *design* from *technical*. =C2=A0The > 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. =C2=A0Therefore, 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. =C2=A0Part of the purpose of the > implementation (after proper design is in place) is to address > performance and other related issues. =C2=A0And part of the design is how= we > define the *interface*. =C2=A0The filename is clearly part of the interfa= ce. > =C2=A0It is part of how devs (and users) interact with portage when writi= ng > ebuilds. =C2=A0Much 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). =C2=A0As 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. =C2=A0I've been an engineer for over 20 year= s, > and I have seen the pitfalls of taking the quick-and-dirty approach just > to slap a new feature into a software app. =C2=A0I'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. =C2=A0For what it's worth, GLEP 55 doe= s > now provide an option (#3: Easily fetchable EAPI inside the ebuild and > one-time extension change) that demonstrates good design. I think what you are missing is that some people (me included) think that the in-file approach is the cleanest and most obvious solution (which also happens to not hurt performance). So if you want "bad design" to be an objective argument you need to back it up with something concrete. For example, could you foresee any actual problems of the in-filename approach? Cause all I was hearing was "it doesn't look nice" which now is "oh no, don't expose metadata". The former is clearly subjective and the latter is already done ($PN-$PV) and doesn't seem to cause any problems. --=20 Best Regards, Piotr Jaroszy=C5=84ski