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