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