1 |
Ciaran McCreesh wrote: |
2 |
|
3 |
> On Sat, 16 May 2009 00:28:36 +0530 |
4 |
> Arun Raghavan <ford_prefect@g.o> wrote: |
5 |
>> As I've stated a long time ago, I'm for this solution. My |
6 |
>> understanding is that there are 2 objections to this: |
7 |
> |
8 |
> 3) It doesn't solve the problem. It doesn't allow things like version |
9 |
> format extensions. |
10 |
> |
11 |
> That's the big one, not the other two. |
12 |
> |
13 |
Debian-style epochs, which were mooted to this list over a year ago, do |
14 |
however, given that we already have SLOT. |
15 |
|
16 |
They're also a lot simpler and do not 'require' a potentially unlimited |
17 |
set of new extensions for every "new format" (look, shiny!) that a herd |
18 |
might experiment with. |
19 |
|
20 |
And again, you haven't explained why an internal format specification |
21 |
should allow NN variants on the format (beyond your usual sniping at |
22 |
the level of developer expertise, which you propose to address by making |
23 |
it easy to mess up the spec, instead of simply expecting people to learn; |
24 |
which they certainly appear capable of doing, as the ebuild tree attests.) |
25 |
|
26 |
In summary, the proposed benefit doesn't seem like one, and certainly not |
27 |
enough to justify the fundamental noob mistake of breaking encapsulation. |
28 |
|
29 |
Personally I remain unconvinced this is even enough to merit the use of |
30 |
epochs. I'd much rather see them kept in reserve for a real issue, and |
31 |
an innovation which actually solves a problem our end-users face. So no, |
32 |
not a "big one" at all; just yet another student attempt at coercion |
33 |
cloaked in obfuscation. No more, no less. |
34 |
|
35 |
'Sometimes I find it hard to believe that people can attach so much of |
36 |
their ego to one particular design, even when the obvious flaws are |
37 |
pointed out. As a wise man once said to me: |
38 |
"There also comes a point where you realise that no one can know |
39 |
everything, so it's not a problem to ask someone or on occasion be |
40 |
wrong.."'[1] |
41 |
|
42 |
Think about it. No? Ah well never mind, didn't really expect you to ever |
43 |
accept you might still have something to learn. No doubt there'll be |
44 |
another 50 or so emails from you next time I catch up on the list. And |
45 |
of course if each one doesn't have a detailed objection, it's enough for |
46 |
you to claim that you've run it past the list. And if they do, it's |
47 |
simply because the person doesn't understand (despite your clear and |
48 |
lucid explanations to the list.) </sarcasm> |
49 |
|
50 |
[project] |
51 |
You are aware that many Gentoo developers simply cba to argue with you? |
52 |
Since the stuff you're proposing often makes no effective difference to |
53 |
what they're doing anyway (it's /that/ useful), it can seem easier simply |
54 |
to let you have your way. Believe it or not, that's how I feel; I'm only |
55 |
speaking now as your GLEPs are so massively flawed, that I've been told |
56 |
I would have to maintain a patched portage were they to go ahead. |
57 |
|
58 |
Happily the only patches required would be to get rid of the crap you're |
59 |
proposing. I *still* resent the extra workload, and the fact that it's |
60 |
only necessitated because you haven't got over the rejection of being the |
61 |
only developer ever to be kicked in such a fashion. Twice. |
62 |
[/project] |
63 |
|
64 |
[1] http://igliot.blogspot.com/ |
65 |
-- |
66 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |