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

[Mark Bateman]

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 27 May 2009 22:43:21 +0100
> Roy Bamford <neddyseagoon <at> gentoo.org> wrote:
> > You chose to ignore "Adding metadata to the filename is not required
> > and is bad system design practice."
> >
> > I assume you agree with that as you chose to snip it, not to refute
> > it with a technical argument?
>
> That's a blind assertion, not a technical argument, in the same way
> that "feeding cows is not necessary, and giving food to cows is bad
> farming practice" is. The GLEP clearly demonstrates its necessity.

The only thing that GLEP55 "clearly demonstrates" is something has to be done, 
such that the EAPI of the ebuild can be determined before the package manager
actually sources the ebuild.

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

>
> > GLEP 55 is a poor piece of technical writing. The title
> > <quote>
> > Title:	Use EAPI-suffixed ebuilds (.ebuild-EAPI)
> > </quote>
> > should be an area to be impvoved not a possible solution that has not
> > even been discussed (in the document)  yet.
>
> 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. 

Present title is crap, simple as that.


>
> > The abstract tells readers more about a proposed solution.
> > <quote>
> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
> > (for example, foo-1.2.3.ebuild-1).
> > </quote>
> > and readers still don't know the problem that it tries to address.
>
> 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

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. 
 


> > The statement of the problem is not entirely correct either ...
> > <quote>The current way of specifying the EAPI in ebuilds is flawed.
> > In order to get the EAPI the package manager needs to source the
> > ebuild,
> > </quote>
> > Nope, in order to get the EAPI, the PM needs to parse the ebuild, it
> > need not source it. Thats a statement of the current design.
>
> 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. 

Parse the ebuild, determine the EAPI, 
configure PackageManager, source ebuild. Problem solved.  QED.

I wonder what portage does at the moment...

Definition of problem is flawed within GLEP55 


>
> > <quote>
> > which itself needs the EAPI in the first place.
> > </quote>
> > Well, thats what current designs do, its a design than can be changed.
>
> ...which is what GLEP 55 is about, yes.
>
> > Until we get to the Abstract solution, the GLEP reads like a sales
> > brouchre, which is what reminded me of VHS vs Betamax.
>
> 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
2) the Abstraction is all about the solution
THEN finally we get the actual problem 
This GLEP starts off with DETAILS!!! precise details 

Again this, as a technical paper is shocking!. And if you have read any 
technical paper or written any that actually got anywhere you would be able
to see that.



> > The
> > <quote>
> > Hurts performance: yes
> > </quote>
> > needs to be quantifed and included in the GLEP, so that readers can
> > make an impartial objective assessment of the alternatives on offer
> > and hopefully support the best technical solution. That need not be
> > the fastest.
>
> 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.
Otherwise it is just a baseless statement and its presence in a technical 
discussion is amateurish
 
ANY technical paper that wants to be taken seriously provides details on 
how tests were performed, how tests were collected.

>
> > A GLEP is not a sales document for any particular design solution.
> > Well, this one is in its present form and it needs to be fixed.
>
> Have you read any GLEPs? Or indeed any other technical papers? It's a
> rare technical paper that advocates an enhancement without stating the
> benefits of that enhancement.
>
> > In short, I support the aims of GLEP 55 but not (yet) the proposed
> > solution as the GLEP has not made any quantitive technical arguments
> > for it being the best solution. There is already plenty of posts on
> > this list suggesting it isn't.
>
> The only solutions that have been proposed that solve the entire
> problem are the extension ones, and between .ebuild-X and .eapi-X.eb is
> mere bikeshedding that won't get decided except by an arbitrary vote.
>

Umm no. A number of solutions have been put forward to solve the problem 
described in GLEP55, 
"means to determine the EAPI of an ebuild pre-sourcing"
 
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.
Infact it has already been stated: 
"Adding metadata to the filename is not required and is bad system 
design practice"

So unless there is some other aspect of the problem that hasn't been described 
in GLEP55, I fail to see any technical reason why encoding into the filename 
is the only solution

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