1 |
Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes: |
2 |
|
3 |
> |
4 |
> -----BEGIN PGP SIGNED MESSAGE----- |
5 |
> Hash: SHA1 |
6 |
> |
7 |
> On Wed, 27 May 2009 22:43:21 +0100 |
8 |
> Roy Bamford <neddyseagoon <at> gentoo.org> wrote: |
9 |
> > You chose to ignore "Adding metadata to the filename is not required |
10 |
> > and is bad system design practice." |
11 |
> > |
12 |
> > I assume you agree with that as you chose to snip it, not to refute |
13 |
> > it with a technical argument? |
14 |
> |
15 |
> That's a blind assertion, not a technical argument, in the same way |
16 |
> that "feeding cows is not necessary, and giving food to cows is bad |
17 |
> farming practice" is. The GLEP clearly demonstrates its necessity. |
18 |
|
19 |
The only thing that GLEP55 "clearly demonstrates" is something has to be done, |
20 |
such that the EAPI of the ebuild can be determined before the package manager |
21 |
actually sources the ebuild. |
22 |
|
23 |
NOT once within GLEP55 or in all the ml posts over all the *MONTHS* has there |
24 |
been unequivocal proof that encoding metadata into the filename of an ebuild |
25 |
is a necessity, so please stop playing that tune it is getting boring |
26 |
|
27 |
> |
28 |
> > GLEP 55 is a poor piece of technical writing. The title |
29 |
> > <quote> |
30 |
> > Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) |
31 |
> > </quote> |
32 |
> > should be an area to be impvoved not a possible solution that has not |
33 |
> > even been discussed (in the document) yet. |
34 |
> |
35 |
> GLEP titles are required to be short. |
36 |
|
37 |
Even with title length restrictions the title can easily be improved. At present |
38 |
it tells the skim reader NOTHING except it is todo with encoding EAPI into |
39 |
the filename. |
40 |
|
41 |
"Means to determine EAPI of ebuild" |
42 |
7 less characters AND actually provides some description of what this GLEP is |
43 |
going to cover not some BS "WTF" title. |
44 |
|
45 |
Present title is crap, simple as that. |
46 |
|
47 |
|
48 |
> |
49 |
> > The abstract tells readers more about a proposed solution. |
50 |
> > <quote> |
51 |
> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds |
52 |
> > (for example, foo-1.2.3.ebuild-1). |
53 |
> > </quote> |
54 |
> > and readers still don't know the problem that it tries to address. |
55 |
> |
56 |
> Because that's down in the 'Problem' section. Your argument appears to |
57 |
> be that no individual paragraph covers every last bit of material in |
58 |
> the GLEP. |
59 |
> |
60 |
|
61 |
No it is not. That is not an abstract, that is jumping straight in with the |
62 |
proposed solution. That is not what an abstraction/summary is for. |
63 |
There is no (formal) length restriction on the abstraction section so it should |
64 |
be taken advantage of. |
65 |
|
66 |
The abstract/summary is to allow those that have a quick look into the paper |
67 |
(after looking at a relevant title...) to tell if it relevant to their interest |
68 |
and whether they should read any further. |
69 |
OR in a big discussion, where a paper is referred to as a logging number, |
70 |
people can quickly ascertain what it is discussing - very important ifmany |
71 |
papers are referenced in a discussion |
72 |
|
73 |
If you have any formal proposal writing experience you would know that |
74 |
|
75 |
As a formal paper this is a joke and I would be embarrassed to be associated |
76 |
with it, luckily I am not. |
77 |
|
78 |
|
79 |
|
80 |
> > The statement of the problem is not entirely correct either ... |
81 |
> > <quote>The current way of specifying the EAPI in ebuilds is flawed. |
82 |
> > In order to get the EAPI the package manager needs to source the |
83 |
> > ebuild, |
84 |
> > </quote> |
85 |
> > Nope, in order to get the EAPI, the PM needs to parse the ebuild, it |
86 |
> > need not source it. Thats a statement of the current design. |
87 |
> |
88 |
> Uhm. No. With the current rules, the package manager cannot parse the |
89 |
> ebuild. It has to use a full bash source. |
90 |
|
91 |
So ... maybe the rules are wrong and they also need to be changed for the |
92 |
complete solution to be realised. |
93 |
|
94 |
Parse the ebuild, determine the EAPI, |
95 |
configure PackageManager, source ebuild. Problem solved. QED. |
96 |
|
97 |
I wonder what portage does at the moment... |
98 |
|
99 |
Definition of problem is flawed within GLEP55 |
100 |
|
101 |
|
102 |
> |
103 |
> > <quote> |
104 |
> > which itself needs the EAPI in the first place. |
105 |
> > </quote> |
106 |
> > Well, thats what current designs do, its a design than can be changed. |
107 |
> |
108 |
> ...which is what GLEP 55 is about, yes. |
109 |
> |
110 |
> > Until we get to the Abstract solution, the GLEP reads like a sales |
111 |
> > brouchre, which is what reminded me of VHS vs Betamax. |
112 |
> |
113 |
> Have you ever read a technical paper? They start off with a brief |
114 |
> introduction that doesn't contain details, then move on to the details |
115 |
> later on. |
116 |
> |
117 |
|
118 |
WHAT! |
119 |
1) The title of this GLEP is all about the solution |
120 |
2) the Abstraction is all about the solution |
121 |
THEN finally we get the actual problem |
122 |
This GLEP starts off with DETAILS!!! precise details |
123 |
|
124 |
Again this, as a technical paper is shocking!. And if you have read any |
125 |
technical paper or written any that actually got anywhere you would be able |
126 |
to see that. |
127 |
|
128 |
|
129 |
|
130 |
> > The |
131 |
> > <quote> |
132 |
> > Hurts performance: yes |
133 |
> > </quote> |
134 |
> > needs to be quantifed and included in the GLEP, so that readers can |
135 |
> > make an impartial objective assessment of the alternatives on offer |
136 |
> > and hopefully support the best technical solution. That need not be |
137 |
> > the fastest. |
138 |
> |
139 |
> It's a simple statement of fact. |
140 |
if it *fact* provide results, provide details of how the results were |
141 |
obtained, provide details so others may reproduce independently, if they want. |
142 |
Such things should be in the paper. |
143 |
Otherwise it is just a baseless statement and its presence in a technical |
144 |
discussion is amateurish |
145 |
|
146 |
ANY technical paper that wants to be taken seriously provides details on |
147 |
how tests were performed, how tests were collected. |
148 |
|
149 |
> |
150 |
> > A GLEP is not a sales document for any particular design solution. |
151 |
> > Well, this one is in its present form and it needs to be fixed. |
152 |
> |
153 |
> Have you read any GLEPs? Or indeed any other technical papers? It's a |
154 |
> rare technical paper that advocates an enhancement without stating the |
155 |
> benefits of that enhancement. |
156 |
> |
157 |
> > In short, I support the aims of GLEP 55 but not (yet) the proposed |
158 |
> > solution as the GLEP has not made any quantitive technical arguments |
159 |
> > for it being the best solution. There is already plenty of posts on |
160 |
> > this list suggesting it isn't. |
161 |
> |
162 |
> The only solutions that have been proposed that solve the entire |
163 |
> problem are the extension ones, and between .ebuild-X and .eapi-X.eb is |
164 |
> mere bikeshedding that won't get decided except by an arbitrary vote. |
165 |
> |
166 |
|
167 |
Umm no. A number of solutions have been put forward to solve the problem |
168 |
described in GLEP55, |
169 |
"means to determine the EAPI of an ebuild pre-sourcing" |
170 |
|
171 |
encoding the EAPI into the filename does not provide any additional benefits |
172 |
over encoding it in a pre-defined position within the files data + one-off |
173 |
extension change. |
174 |
Infact it has already been stated: |
175 |
"Adding metadata to the filename is not required and is bad system |
176 |
design practice" |
177 |
|
178 |
So unless there is some other aspect of the problem that hasn't been described |
179 |
in GLEP55, I fail to see any technical reason why encoding into the filename |
180 |
is the only solution |
181 |
|
182 |
Now if there is an actual technical reason, a reason that isn't present in |
183 |
GLEP55, then it is further proof that GLEPP55 is not suitable for the task and |
184 |
needs to be rejected in its present form |