1 |
On Thu, 28 May 2009 08:28:12 +0200 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> - Try to avoid subjective statements. Statements like "C++ feels |
4 |
> better" don't add anything to the discussion and are objectively |
5 |
> wrong for me, so they have no place in a technical discussion |
6 |
|
7 |
You mean like "EAPI in the filename feels bad"? I agree, that has no |
8 |
place in a technical discussion. |
9 |
|
10 |
> > Not once has there been an equally good alternative proposed. |
11 |
> |
12 |
> That's subjective, and let me be the first one to disagree. |
13 |
|
14 |
No, it's entirely objective. GLEP 55 clearly shows how the filename |
15 |
based options are objectively better than anything else. |
16 |
|
17 |
> > > > GLEP titles are required to be short. |
18 |
> Yes, that is a reasonable demand. It is completely independent of the |
19 |
> demand that the title describes the _problem_ and not your solution. |
20 |
|
21 |
The title describes the proposed enhancement. |
22 |
|
23 |
> > Doesn't cover the intent of the enhancement. The intent of the |
24 |
> > enhancement is to use EAPI suffixed ebuilds. |
25 |
> |
26 |
> No, the intent is to find a better way to determine the EAPI. One |
27 |
> proposed solution is the use of a suffix. Please stop trying to |
28 |
> distract people in semantic games, it is dishonest. |
29 |
|
30 |
No, the intent of the enhancement is to switch to EAPI in the filename. |
31 |
|
32 |
> This is an important point - define the problem first, then discuss |
33 |
> solutions. |
34 |
|
35 |
The problem is defined as the first part of the main body of the GLEP. |
36 |
|
37 |
> > Yes, and the quick summary of the GLEP is that EAPI suffixed file |
38 |
> > extensions should be used for ebuilds. |
39 |
> |
40 |
> No, that is the solution favoured by one group of people. |
41 |
|
42 |
...and it is the proposed enhancement. |
43 |
|
44 |
> > You're being overly harsh on Piotr there. GLEPs aren't supposed to |
45 |
> > be written to peer review journal standards -- they're supposed to |
46 |
> > be technical material that can be understood by the appropriate |
47 |
> > audience and used to propose an enhancement, not something that has |
48 |
> > to stand in archives for a thousand years. |
49 |
> And still one would expect a minimal coherence - stating the problem |
50 |
> (not there), discussing alternatives (incomplete and phrased in a way |
51 |
> to make them look extra bad) and maybe a comparison (mostly missing). |
52 |
|
53 |
Please re-read the GLEP. All the things you claim aren't there are. |
54 |
|
55 |
> Which points at a simple solution that gets mostly ignored: Since we |
56 |
> already state EAPI explicitly we can restrict ourselves to parsing it |
57 |
> (with a regexp, maybe) instead of having to source the ebuild. Which |
58 |
> has to happen anyway as soon as you need metadata ... |
59 |
|
60 |
Uhm. No. It's needed as soon as you need metadata if there's no cache. |
61 |
Biiiiig difference. If we were sourcing for metadata regardless, it'd |
62 |
be unusably slow. |
63 |
|
64 |
> > Congratulations. That is what this whole thing is about, and GLEP 55 |
65 |
> > presents the best way of doing that changing. |
66 |
> |
67 |
> No, GLEP55 is the hackish way of sweeping it under the rug. Feel free |
68 |
> to implement it in an experimental overlay and report back what your |
69 |
> experiences are in, say, 3 months ... |
70 |
|
71 |
kdebuild-1 demonstrated the viability of the technique. |
72 |
|
73 |
> > > Definition of problem is flawed within GLEP55 |
74 |
> > |
75 |
> > No, the definition of the problem is entirely accurate and correct. |
76 |
> |
77 |
> ... wait, you defined the problem now? I thought GLEP55 was all about |
78 |
> the solution. Or are you deliberately trying a switch-and-bate ? |
79 |
|
80 |
Did you read GLEP 55? |
81 |
|
82 |
> > The title describes the desired enhancement, yes. |
83 |
> ... which completely ignores stating the problem. |
84 |
|
85 |
... because there's a length limit. The title is not a substitute for |
86 |
reading the GLEP. |
87 |
|
88 |
> > > 2) the Abstraction is all about the solution |
89 |
> > |
90 |
> > The abstract describes the desired enhancement in more detail, yes. |
91 |
> ... enhancing what to achieve what why? |
92 |
|
93 |
The abstract is not a substitute for reading the GLEP. |
94 |
|
95 |
> > > THEN finally we get the actual problem |
96 |
> > |
97 |
> > The main proposal then expands upon the background and reasoning |
98 |
> > behind the enhancement, yes. |
99 |
> Oh, you gotta read it backwards. That's awesome. No wait, the other |
100 |
> thing. Stupid! |
101 |
|
102 |
You read the introductory material, then if you want details you read |
103 |
the rest. Simple. |
104 |
|
105 |
> > It's not something that's only true as a |
106 |
> > result of an implementation; implementations can be improved, but |
107 |
> > penalties from definition can't be fixed. |
108 |
> Hmm. I'm not quite sure how to parse that. Does that mean that we |
109 |
> need to abstractly discuss various options (which would go against |
110 |
> your interpretation of the process), or does that mean that the idea |
111 |
> of glep55 is flawed (which would be a rather interesting concession |
112 |
> coming from you)? |
113 |
|
114 |
I shall explain it to you in simple terms: there can be two reasons for |
115 |
"x is slower". Either the implementation of x is bad, in which case it |
116 |
can be improved, or the definition of what x has to do requires |
117 |
slowness, in which case you can't fix it. For example, an |
118 |
implementation might be slow because it doesn't carefully avoid doing |
119 |
more disk work than necessary, in which case it can be fixed, or it |
120 |
might be slow because the specification of what it does requires it to |
121 |
do lots of disk work, in which case it can't. |
122 |
|
123 |
> > > Infact it has already been stated: |
124 |
> > > "Adding metadata to the filename is not required and is bad system |
125 |
> > > design practice" |
126 |
> > |
127 |
> > Stating something doesn't make it true. You could just as easily |
128 |
> > argue that having PV in the filename is bad. |
129 |
> |
130 |
> Ignoring it doesn't make it go away. Reasonable discussion would be |
131 |
> the best thing to do now ... are you willing to do that instead of |
132 |
> running in circles and barking the same dog-matic statements? |
133 |
|
134 |
Please go back to your "nothing subjective" comment. |
135 |
|
136 |
> > > Now if there is an actual technical reason, a reason that isn't |
137 |
> > > present in GLEP55, then it is further proof that GLEPP55 is not |
138 |
> > > suitable for the task and needs to be rejected in its present form |
139 |
> > |
140 |
> > The reason is that there is no equally good alternative. |
141 |
> |
142 |
> The reason is that GLEP55 is no reasonable alternative to the rest. |
143 |
|
144 |
We've already established that a fix is necessary. Now we're just |
145 |
discussing which fix is best, and GLEP 55 conclusively provides the |
146 |
answer. |
147 |
|
148 |
-- |
149 |
Ciaran McCreesh |