Re: [gentoo-dev] How not to discuss

[Piotr Jaroszyński]

2009/5/28 Joe Peterson <lavajoe@g.o>:
> 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*.  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.

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.

-- 
Best Regards,
Piotr Jaroszyński