1 |
Ciaran McCreesh posted on Sat, 23 Jun 2012 10:38:33 +0100 as excerpted: |
2 |
|
3 |
> On Sat, 23 Jun 2012 09:53:37 +0200 Pacho Ramos <pacho@g.o> wrote: |
4 |
>> Don't you see this way of handling things, with such and obscure way of |
5 |
>> getting things accepted for every EAPI is really hurting us? |
6 |
> |
7 |
> What is hurting is people demanding features without specifying what the |
8 |
> problem is, how it will be solved or what the impact on users or |
9 |
> developers will be, and then taking up everyone's time with complaints |
10 |
> when they don't get magical flying unicorns instantly. |
11 |
> |
12 |
> If you want something, you either have to do the work yourself, or find |
13 |
> someone to do it. And here's the thing: you're assuming that "the work" |
14 |
> is trivial, which for some of the things you're discussing it really |
15 |
> isn't. The PMS wording is the trivial bit that comes at the end once the |
16 |
> problem and solution have been worked out. |
17 |
|
18 |
Without weighing in on either side of the technical details of this |
19 |
debate, it's possible to observe two things: |
20 |
|
21 |
1) Fact: Unfortunately, your method of argument, Ciaran, doesn't endear |
22 |
you to a number of devs. Some may have the impulse to reject an argument |
23 |
simply because it comes from you. |
24 |
|
25 |
2) PMS is supposed to be about specifying things well enough that all |
26 |
three PMs can implement compatible ebuild/eclass/etc interpretation and |
27 |
execution. |
28 |
|
29 |
3) Given the above, it would be of /great/ benefit to your argument if |
30 |
either Zac or Brian (or preferably both) stepped up from time to time and |
31 |
said yes, this is really an issue. |
32 |
|
33 |
Not that they'd necessarily reply to everything you do, but if they could |
34 |
reply once in support, such that you could refer people back to those |
35 |
replies from elsewhere... |
36 |
|
37 |
This would be of particular help concerning the multi-arch work where |
38 |
there's already an implementation for portage, but it is argued a proper |
39 |
spec is still lacking. Obviously if it's approved Brian's going to need |
40 |
to implement it as well as you, and having him too say there's not enough |
41 |
there to do so, ideally with his estimation of where the process is in |
42 |
terms of work needed, as well, would go quite a long way. Similarly but |
43 |
from a different angle, if Zac says that he's not satisfied with the |
44 |
specification even with portage's already implementing what's there and |
45 |
having it proven to work (for whatever definition of "work"), that goes |
46 |
quite a way toward giving the argument for a better spec some serious |
47 |
support, as well. |
48 |
|
49 |
|
50 |
If you can't get those statements, then round and round the discussion |
51 |
will go until people are sick, and until people simply ignore your |
52 |
position and push /something/ thru, which would be a real shame if it |
53 |
could be practically[1] made better, or the practical ideal of PMS ends |
54 |
up getting lost in the results. |
55 |
|
56 |
And if you /can/ get those statements, why are we still going round and |
57 |
round with all this? (Again, references to said statements may be |
58 |
necessary from time to time, given the quantity of posts and the |
59 |
likelihood single answers in support of your position could be missed.) |
60 |
|
61 |
|
62 |
[1] Practically: favorable cost/benefit ratio for the work needed. |
63 |
|
64 |
-- |
65 |
Duncan - List replies preferred. No HTML msgs. |
66 |
"Every nonfree program has a lord, a master -- |
67 |
and if you use the program, he is your master." Richard Stallman |