1 |
Am 28.11.2011 20:16, schrieb Nikos Chantziaras: |
2 |
> On 11/28/2011 06:59 PM, Florian Philipp wrote: |
3 |
>> Am 28.11.2011 17:15, schrieb Nikos Chantziaras: |
4 |
>>> On 11/28/2011 02:29 PM, Albert W. Hopkins wrote: |
5 |
>>>> On Sun, 2011-11-27 at 20:28 +0100, Andrea Conti wrote: |
6 |
>>>>> With 100% repeatability, mind you, which does raise same questions on |
7 |
>>>>> the amount of testing done before release. Yes, it's ~arch and |
8 |
>>>>> rc_parallel is explicitly marked "experimental", but it's not expected |
9 |
>>>>> to be completely and consistently broken, either. |
10 |
>>>>> |
11 |
>>>>> If that sounds like I'm ranting, it's because I just spent about an |
12 |
>>>>> hour |
13 |
>>>>> getting three machines affected by this problem back into working |
14 |
>>>>> state. |
15 |
>>>>> |
16 |
>>>>> If anyone still has it installed, it's time to sync and downgrade :) |
17 |
>>>> |
18 |
>>>> Sorry to add more to the whining but... |
19 |
>>>> |
20 |
>>>> Yes, you are in the testing tree. Yes, as a member of testing, *you* |
21 |
>>>> expect things will occasionally break, and it is *your* job to test |
22 |
>>>> things, break them, and report bugs. |
23 |
>>> |
24 |
>>> Generally true, but not when something is obviously broken. That means |
25 |
>>> not even its upstream dev bothered to test it. |
26 |
>>> |
27 |
>>> ~arch is for "we think this works, but please give it a go in case there |
28 |
>>> are problems". It's *not* for "we have no idea if this works because we |
29 |
>>> didn't even try it once". |
30 |
>> |
31 |
>> Do you have any idea how much time you can spend with the kind of system |
32 |
>> testing you propose? |
33 |
> |
34 |
> About 2 minutes? Enabling the parallel startup thingy and rebooting the |
35 |
> machine. There you go :-/ |
36 |
> |
37 |
> |
38 |
|
39 |
Oh, you just want to test the features *you* use, understood. What about |
40 |
*my* (imaginary) issue with rc_depend_strict="YES" or one of the other |
41 |
two dozen parameters you can set there. Not even considering different |
42 |
init scripts in different run levels and so forth. I, for example, start |
43 |
dmcrypt _before_ lvm because all lvm volumes are on one encrypted |
44 |
partition. Do you want that to be tested as well or is your experimental |
45 |
feature more valuable than mine? |
46 |
|
47 |
And that's only the tip of the iceberg. What about all the other scripts |
48 |
and config files which belong to baselayout2? What about all other |
49 |
packages? If the openrc dev has to test his configs, surely the SSH dev |
50 |
also has to because a crashing ssh daemon leaves everyone with a |
51 |
headless server in quite a uncomfortable situation. |
52 |
|
53 |
Let's make a simple example, shall we? Let's say we only want to test |
54 |
all yes/no variables in rc.conf. There are 7 of them. We also remove |
55 |
those two only affecting output and you still have 5. That are 2^5=32 |
56 |
combinations that you consider valid and therefore want to be tested. |
57 |
Now we have a dev spending one hour doing nothing but reboots. Even |
58 |
changing each variable (I counted 27 in total) only once takes a lot of |
59 |
time and also different hardware capabilities (like a second network |
60 |
interface). |
61 |
|
62 |
Sorry if that sounded harsh but really, what you want is what Redhat |
63 |
(maybe) does for its releases and those only occur every few years and |
64 |
cost lots of money. |
65 |
|
66 |
Regards, |
67 |
Florian Philipp |