1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
2 |
Hash: SHA1
|
3 |
|
4 |
On Wed, 27 May 2009 22:43:21 +0100
|
5 |
Roy Bamford <neddyseagoon@g.o> wrote:
|
6 |
> You chose to ignore "Adding metadata to the filename is not required |
7 |
> and is bad system design practice." |
8 |
> |
9 |
> I assume you agree with that as you chose to snip it, not to refute |
10 |
> it with a technical argument? |
11 |
|
12 |
That's a blind assertion, not a technical argument, in the same way
|
13 |
that "feeding cows is not necessary, and giving food to cows is bad
|
14 |
farming practice" is. The GLEP clearly demonstrates its necessity.
|
15 |
|
16 |
> GLEP 55 is a poor piece of technical writing. The title |
17 |
> <quote> |
18 |
> Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) |
19 |
> </quote> |
20 |
> should be an area to be impvoved not a possible solution that has not |
21 |
> even been discussed (in the document) yet. |
22 |
|
23 |
GLEP titles are required to be short.
|
24 |
|
25 |
> The abstract tells readers more about a proposed solution. |
26 |
> <quote> |
27 |
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds |
28 |
> (for example, foo-1.2.3.ebuild-1). |
29 |
> </quote> |
30 |
> and readers still don't know the problem that it tries to address. |
31 |
|
32 |
Because that's down in the 'Problem' section. Your argument appears to
|
33 |
be that no individual paragraph covers every last bit of material in
|
34 |
the GLEP.
|
35 |
|
36 |
> The statement of the problem is not entirely correct either ... |
37 |
> <quote>The current way of specifying the EAPI in ebuilds is flawed. |
38 |
> In order to get the EAPI the package manager needs to source the |
39 |
> ebuild, |
40 |
> </quote> |
41 |
> Nope, in order to get the EAPI, the PM needs to parse the ebuild, it |
42 |
> need not source it. Thats a statement of the current design. |
43 |
|
44 |
Uhm. No. With the current rules, the package manager cannot parse the
|
45 |
ebuild. It has to use a full bash source.
|
46 |
|
47 |
> <quote> |
48 |
> which itself needs the EAPI in the first place. |
49 |
> </quote> |
50 |
> Well, thats what current designs do, its a design than can be changed. |
51 |
|
52 |
...which is what GLEP 55 is about, yes.
|
53 |
|
54 |
> Until we get to the Abstract solution, the GLEP reads like a sales |
55 |
> brouchre, which is what reminded me of VHS vs Betamax. |
56 |
|
57 |
Have you ever read a technical paper? They start off with a brief
|
58 |
introduction that doesn't contain details, then move on to the details
|
59 |
later on.
|
60 |
|
61 |
> The |
62 |
> <quote> |
63 |
> Hurts performance: yes |
64 |
> </quote> |
65 |
> needs to be quantifed and included in the GLEP, so that readers can |
66 |
> make an impartial objective assessment of the alternatives on offer |
67 |
> and hopefully support the best technical solution. That need not be |
68 |
> the fastest. |
69 |
|
70 |
It's a simple statement of fact.
|
71 |
|
72 |
> A GLEP is not a sales document for any particular design solution. |
73 |
> Well, this one is in its present form and it needs to be fixed. |
74 |
|
75 |
Have you read any GLEPs? Or indeed any other technical papers? It's a
|
76 |
rare technical paper that advocates an enhancement without stating the
|
77 |
benefits of that enhancement.
|
78 |
|
79 |
> In short, I support the aims of GLEP 55 but not (yet) the proposed |
80 |
> solution as the GLEP has not made any quantitive technical arguments |
81 |
> for it being the best solution. There is already plenty of posts on |
82 |
> this list suggesting it isn't. |
83 |
|
84 |
The only solutions that have been proposed that solve the entire
|
85 |
problem are the extension ones, and between .ebuild-X and .eapi-X.eb is
|
86 |
mere bikeshedding that won't get decided except by an arbitrary vote.
|
87 |
|
88 |
- --
|
89 |
Ciaran McCreesh
|
90 |
-----BEGIN PGP SIGNATURE-----
|
91 |
Version: GnuPG v2.0.9 (GNU/Linux)
|
92 |
|
93 |
iEYEARECAAYFAkodtiAACgkQ96zL6DUtXhEPKACeMX9DiIW62tCo/uHy74L7erxH
|
94 |
334AoIHqEb9SJ1QKzaosm1q1U4e7YlbZ
|
95 |
=jasp
|
96 |
-----END PGP SIGNATURE----- |