Re: [gentoo-dev] How not to discuss

[Alec Warner]

On Thu, May 28, 2009 at 12:15 PM, Joe Peterson <lavajoe@g.o> 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
>
>