[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

David Leverton <levertond@××××××××××.com> posted
200905161059.53706.levertond@××××××××××.com, excerpted below, on  Sat, 16
May 2009 10:59:53 +0100:

> But the point isn't that we want to be able to do those things.  The
> point is that if the EAPI is in the filename, it's blatantly obvious
> that it has to be static, but adding strange and unintuitive
> restrictions on which shell constructs can be used is, well, strange and
> unintuitive.

Has it really come down to this?

I mean, for the longest time, the main (among many) boosting claim seemed 
to be that the speed difference between in-file and in-filename made the 
former prohibitive in practice.  Perhaps the benchmarks the council asked 
for are disproving this.  I don't know but I know I sure see a lot less 
of that claim, call it a deemphasis if you will, now, only that the 
filename method (i.e. glep55) isn't slower. <shrug>

Now, the main argument seems to be that glep55 filename based eapis are 
"more intuitive".  

The argument was originally made that a simple highly specified EAPI= 
declaration in the file itself was too restrictive of all the ways it 
could be specified now -- until it began to be pointed out every time the 
argument was made that the filename method was very similarly 
restricted.  

Now that argument has been debunked and no longer works as it did, so it 
seems the reasons now being presented are what they have left, that the 
filename restriction is "blatantly obvious", while the in-file EAPI= 
restrictions are "unintuitive".

I'd argue no, it's no more unintuitive than any other format definition 
choice.  It's the basic format definition, using the long accepted method 
of "magic values" at a "magic location" to define the format version.  
That's very basic definitional, restricted only to the degree necessary 
for practical application of the definition.  Therefore, it's not 
unintuitive, or at least, certainly no more so than arbitrarily defining 
it to be in the filename instead, because "intuitive" now gets defined by 
the format definition at an extremely basic level, well below the level 
at which all the "intuitive or not" fancy stuff gets addressed.

Regardless, the practical effect is the same, (relatively) severe 
restrictions from the extremely loose definition we have now.  The 
restrictions are even similar.  Thus, it's only an argument over how 
"intuitive" it is, and, well, a stable "base" definition that's 
unchanging is certainly going to look more "intuitive" than say, what 
features are in each EAPI, the much more difficult and "unintuitive" 
thing devs are already trying to track.

Anyway, if it has come down to arguing how intuitive the two opposing 
options may be, that's GOOD news indeed!  It means the important 
questions are, one way or another, getting resolved.  After that, 
ultimately, it's a council judgment call, and we're actually getting 
close!

Unfortunately, "close" is a relative term. =:^(  Realistically?
I'm not sure it's going to resolve by the end of this council's term, but 
provided the elections don't shake things up too badly, it actually looks 
possible to do so reasonably within the /next/ council's term.  We've 
never actually had it (realistically) that close before!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman