1 |
On Wed, 27 May 2009 23:26:25 +0000 (UTC) |
2 |
Mark Bateman <couldbe@××××.com> wrote: |
3 |
> NOT once within GLEP55 or in all the ml posts over all the *MONTHS* |
4 |
> has there been unequivocal proof that encoding metadata into the |
5 |
> filename of an ebuild is a necessity, so please stop playing that |
6 |
> tune it is getting boring |
7 |
|
8 |
Not once has there been an equally good alternative proposed. |
9 |
|
10 |
> > GLEP titles are required to be short. |
11 |
> |
12 |
> Even with title length restrictions the title can easily be improved. |
13 |
> At present it tells the skim reader NOTHING except it is todo with |
14 |
> encoding EAPI into the filename. |
15 |
> |
16 |
> "Means to determine EAPI of ebuild" |
17 |
> 7 less characters AND actually provides some description of what this |
18 |
> GLEP is going to cover not some BS "WTF" title. |
19 |
|
20 |
Doesn't cover the intent of the enhancement. The intent of the |
21 |
enhancement is to use EAPI suffixed ebuilds. |
22 |
|
23 |
> > Because that's down in the 'Problem' section. Your argument appears |
24 |
> > to be that no individual paragraph covers every last bit of |
25 |
> > material in the GLEP. |
26 |
> > |
27 |
> |
28 |
> No it is not. That is not an abstract, that is jumping straight in |
29 |
> with the proposed solution. That is not what an abstraction/summary |
30 |
> is for. There is no (formal) length restriction on the abstraction |
31 |
> section so it should be taken advantage of. |
32 |
> |
33 |
> The abstract/summary is to allow those that have a quick look into |
34 |
> the paper (after looking at a relevant title...) to tell if it |
35 |
> relevant to their interest and whether they should read any further. |
36 |
> OR in a big discussion, where a paper is referred to as a logging |
37 |
> number, people can quickly ascertain what it is discussing - very |
38 |
> important ifmany papers are referenced in a discussion |
39 |
|
40 |
Yes, and the quick summary of the GLEP is that EAPI suffixed file |
41 |
extensions should be used for ebuilds. |
42 |
|
43 |
> If you have any formal proposal writing experience you would know that |
44 |
> |
45 |
> As a formal paper this is a joke and I would be embarrassed to be |
46 |
> associated with it, luckily I am not. |
47 |
|
48 |
You're being overly harsh on Piotr there. GLEPs aren't supposed to be |
49 |
written to peer review journal standards -- they're supposed to be |
50 |
technical material that can be understood by the appropriate audience |
51 |
and used to propose an enhancement, not something that has to stand in |
52 |
archives for a thousand years. |
53 |
|
54 |
> > Uhm. No. With the current rules, the package manager cannot parse |
55 |
> > the ebuild. It has to use a full bash source. |
56 |
> |
57 |
> So ... maybe the rules are wrong and they also need to be changed for |
58 |
> the complete solution to be realised. |
59 |
|
60 |
Congratulations. That is what this whole thing is about, and GLEP 55 |
61 |
presents the best way of doing that changing. |
62 |
|
63 |
> Parse the ebuild, determine the EAPI, |
64 |
> configure PackageManager, source ebuild. Problem solved. QED. |
65 |
> |
66 |
> I wonder what portage does at the moment... |
67 |
|
68 |
It uses bash to do the sourcing, as it has to. And the GLEP covers why |
69 |
the file extension method is better than parsing to get EAPI. |
70 |
|
71 |
> Definition of problem is flawed within GLEP55 |
72 |
|
73 |
No, the definition of the problem is entirely accurate and correct. |
74 |
|
75 |
> > Have you ever read a technical paper? They start off with a brief |
76 |
> > introduction that doesn't contain details, then move on to the |
77 |
> > details later on. |
78 |
> |
79 |
> WHAT! |
80 |
> 1) The title of this GLEP is all about the solution |
81 |
|
82 |
The title describes the desired enhancement, yes. |
83 |
|
84 |
> 2) the Abstraction is all about the solution |
85 |
|
86 |
The abstract describes the desired enhancement in more detail, yes. |
87 |
|
88 |
> THEN finally we get the actual problem |
89 |
|
90 |
The main proposal then expands upon the background and reasoning behind |
91 |
the enhancement, yes. |
92 |
|
93 |
> > It's a simple statement of fact. |
94 |
> if it *fact* provide results, provide details of how the results were |
95 |
> obtained, provide details so others may reproduce independently, if |
96 |
> they want. Such things should be in the paper. |
97 |
|
98 |
It's true by definition. It's not something that's only true as a |
99 |
result of an implementation; implementations can be improved, but |
100 |
penalties from definition can't be fixed. |
101 |
|
102 |
> encoding the EAPI into the filename does not provide any additional |
103 |
> benefits over encoding it in a pre-defined position within the files |
104 |
> data + one-off extension change. |
105 |
|
106 |
This is covered by GLEP 55. |
107 |
|
108 |
> Infact it has already been stated: |
109 |
> "Adding metadata to the filename is not required and is bad system |
110 |
> design practice" |
111 |
|
112 |
Stating something doesn't make it true. You could just as easily argue |
113 |
that having PV in the filename is bad. |
114 |
|
115 |
> Now if there is an actual technical reason, a reason that isn't |
116 |
> present in GLEP55, then it is further proof that GLEPP55 is not |
117 |
> suitable for the task and needs to be rejected in its present form |
118 |
|
119 |
The reason is that there is no equally good alternative. |
120 |
|
121 |
-- |
122 |
Ciaran McCreesh |