-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 May 2009 22:43:21 +0100 Roy Bamford <neddyseag...@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. > 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. > 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. > 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. > <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. > 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. > 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. - -- Ciaran McCreesh -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodtiAACgkQ96zL6DUtXhEPKACeMX9DiIW62tCo/uHy74L7erxH 334AoIHqEb9SJ1QKzaosm1q1U4e7YlbZ =jasp -----END PGP SIGNATURE-----
