systemd and changes

[drago01]

On Mon, Aug 23, 2010 at 11:22 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
> On Mon, 23 Aug 2010, Bill Nottingham wrote:
>
>> Mike McGrath (mmcgrath at redhat.com) said:
>> > > My concern with this line of thinking is that you're asking us to quantify
>> > > the unknown unknown, and define a time period of testing which is
>> > > 'long enough' for us to catch all the unknown unknowns. This seems
>> > > impractical, in as much as it doesn't give us any clear criteria to define
>> > > success with.
>> >
>> > It's just risk management.  I think we'd be better off acknowledging there
>> > are unknown unknowns and try to mitigate them.
>>
>> Sure, but when you say 'we should hold off X period of time' in order to
>> mitigate unknown unknowns, how do you define 'X'? How do you know when it's
>> ready? All I'm seeing are appeals to gut feelings. We can all say that 'more
>> time == more testing', but how do you claim 'good enough'?
>>
>
> I'd say one release is good enough for Fedora.
>
>> > ready.  Unfortunately that's not the path we seem to be on.  We unwisely
>> > seemed to declare it ready before anyone even saw it then we ignored what
>> > we didn't know as if we knew there were going to be no problems.  The sad
>> > thing is that's such an easy fix by making brand new features for core
>> > components like this opt in, even if it's just for a single release.
>>
>> Having to support multiple boot paths for the system, making everyone
>> who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
>> isn't exactly an 'easy fix' - it *adds* complication to both paths.
>>
>
> I'd rather have multiple boot paths to choose from then only one boot path
> that is 2 months old.

Being "2 months old" isn't a problem in itself ... bugs on the other
hand might be if they can't be fixed in time (this does not include
already fixed ones).