Re: [gentoo-dev] Re: Gentoo Council Reminder for May 28

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 4847 bytes --]

On Wed, 27 May 2009 23:26:25 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> NOT once within GLEP55 or in all the ml posts over all the *MONTHS*
> has there been unequivocal proof that encoding metadata into the
> filename of an ebuild is a necessity, so please stop playing that
> tune it is getting boring

Not once has there been an equally good alternative proposed.

> > GLEP titles are required to be short.
> 
> Even with title length restrictions the title can easily be improved.
> At present it tells the skim reader NOTHING except it is todo with
> encoding EAPI into the filename.
>  
> "Means to determine EAPI of ebuild"
> 7 less characters AND actually provides some description of what this
> GLEP is going to cover not some BS "WTF" title. 

Doesn't cover the intent of the enhancement. The intent of the
enhancement is to use EAPI suffixed ebuilds.

> > Because that's down in the 'Problem' section. Your argument appears
> > to be that no individual paragraph covers every last bit of
> > material in the GLEP.
> > 
> 
> No it is not. That is not an abstract, that is jumping straight in
> with the proposed solution. That is not what an abstraction/summary
> is for. There is no (formal) length restriction on the abstraction
> section so it should be taken advantage of. 
> 
> The abstract/summary is to allow those that have a quick look into
> the paper (after looking at a relevant title...) to tell if it
> relevant to their interest and whether they should read any further. 
> OR in a big discussion, where a paper is referred to as a logging
> number, people can quickly ascertain what it is discussing - very
> important ifmany papers are referenced in a discussion

Yes, and the quick summary of the GLEP is that EAPI suffixed file
extensions should be used for ebuilds.

> If you have any formal proposal writing experience you would know that
> 
> As a formal paper this is a joke and I would be embarrassed to be
> associated with it, luckily I am not. 

You're being overly harsh on Piotr there. GLEPs aren't supposed to be
written to peer review journal standards -- they're supposed to be
technical material that can be understood by the appropriate audience
and used to propose an enhancement, not something that has to stand in
archives for a thousand years.

> > Uhm. No. With the current rules, the package manager cannot parse
> > the ebuild. It has to use a full bash source.
> 
> So ... maybe the rules are wrong and they also need to be changed for
> the complete solution to be realised.

Congratulations. That is what this whole thing is about, and GLEP 55
presents the best way of doing that changing.

> Parse the ebuild, determine the EAPI, 
> configure PackageManager, source ebuild. Problem solved.  QED.
> 
> I wonder what portage does at the moment...

It uses bash to do the sourcing, as it has to. And the GLEP covers why
the file extension method is better than parsing to get EAPI.

> Definition of problem is flawed within GLEP55 

No, the definition of the problem is entirely accurate and correct.

> > Have you ever read a technical paper? They start off with a brief
> > introduction that doesn't contain details, then move on to the
> > details later on.
> 
> WHAT!
> 1) The title of this GLEP is all about the solution

The title describes the desired enhancement, yes.

> 2) the Abstraction is all about the solution

The abstract describes the desired enhancement in more detail, yes.

> THEN finally we get the actual problem 

The main proposal then expands upon the background and reasoning behind
the enhancement, yes.

> > It's a simple statement of fact.
> if it *fact* provide results, provide details of how the results were 
> obtained, provide details so others may reproduce independently, if
> they want. Such things should be in the paper.

It's true by definition. It's not something that's only true as a
result of an implementation; implementations can be improved, but
penalties from definition can't be fixed.

> encoding the EAPI into the filename does not provide any additional
> benefits over encoding it in a pre-defined position within the files
> data + one-off extension change.

This is covered by GLEP 55.

> Infact it has already been stated: 
> "Adding metadata to the filename is not required and is bad system 
> design practice"

Stating something doesn't make it true. You could just as easily argue
that having PV in the filename is bad.

> Now if there is an actual technical reason, a reason that isn't
> present in GLEP55, then it is further proof that GLEPP55 is not
> suitable for the task and needs to be rejected in its present form

The reason is that there is no equally good alternative.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]