systemd and changes

[Eric Sandeen]

Mike McGrath wrote:
> On Tue, 24 Aug 2010, Eric Sandeen wrote:
> 
>> Adam Williamson wrote:
>>> On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote:
>>>
>>>> It's just risk management.  I think we'd be better off acknowledging there
>>>> are unknown unknowns and try to mitigate them.  One way we could have done
>>>> that this time around was making it an optional feature (as Matt was
>>>> mentioning in a previous email) for F14 and then decide in F15 if it was
>>>> 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.
>>> Well, ironically enough, Lennart's last big revolution illustrates the
>>> problem with that. PulseAudio - previously PolypAudio, remember - was
>>> 'opt-in' for several releases; it was packaged in Fedora and many other
>>> major distributions, you could enable it just by installing it. It was
>>> used by approximately no-one. People just don't opt in to big bits of
>>> infrastructural change unless they have some very specific reason to do
>>> so; booting the system more or less works for most people, so why would
>>> they 'opt in' to a new init daemon?
>> If it's worth the revolution, wouldn't people choose to opt in?
>>
>> If nobody ever opts in, perhaps it's not worth the revolution?
>>
>> Just a thought ;)
>>
> 
> People like you and me would opt-in.  (well I would on some hosts) because
> we know what we're doing.  Expert eyes get a look at it before it's forced
> onto our users, who are already leaving in leaps and bounds.

I would opt in -if- I saw some benefit to it.  I probably wouldn't opt in
if it looked like change for the sake of change/shininess/newness.

-Eric

> 	-Mike