systemd and changes

[Rudolf Kastl]

2010/8/24 Lennart Poettering <mzerqung at 0pointer.de>:
> On Tue, 24.08.10 12:56, Mike McGrath (mmcgrath at redhat.com) wrote:
>
>>
>> On Tue, 24 Aug 2010, Adam Williamson wrote:
>>
>> > On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
>> >
>> > > 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.
>> >
>> > Again, Pulse/PolypAudio seems to suggest that this is not the case. Why
>> > didn't expert eyes who knew what they were doing migrate to that before
>> > it become default? Or, alternatively, if the expert eyes which knew what
>> > they were doing did migrate, why didn't they catch the bugs that others
>> > encountered when it became default?
>> >
>>
>> If us experts aren't even willing to opt-in in modest enough numbers to
>> test it, why on earth would we force it on people at all?
>
> Well, here's are two simple facts for you:
>
> 1) if things are not used they tend to have bugs
> 2) if things have bugs they are not used

i am pretty sure that matches with most peoples opinion. infact thats
why i am personally a rawhide user where i expect to have the newest
things first (though it would be nice of the maintainer did do some
basic tests himself to ensure atleast a working system for him
personally before he pushed it into rawhide as default) to be able to
really test it before i have to support people in #fedora with
actually less technical expertize.
change management is usually not about things that go wrong but about
things that can go wrong. aka proper testing and planning before
having "live/production" systems.
 it really wouldnt have hurt to test out the "complete system" means
also all the raised potential issues on the checklist you do not feel
responsible for as systemd maintainer. while everything might look
shiny from one single point of view, there are definitely more povs.
and while you personally dont care about some technologies we have
like e.g. iscsi and alot others that were named... they might be
critical to others. what i miss a bit personally is simply seeing
potential implications for the users that are not capable of switching
back to something else because they lack the expertize. or do not
understand some wierd workarounds published somewhere to get stuff
working because there wont be many how tos when the new system will go
live. maybe trying to think from the perspective of a potential user
when it is about a release would be a good approach. i am really
curious what all turns out to be broken in the end... and no matter
which systems fault it is. if it is coming up because of a too quick
change i will definitely blame the process and the lack of
testing/time to get things straight. That said, thanks for your effort
in trying to improve a system.

>
> Acknowledging this: if you want to innovate you have no other option
> than pushing things to the people, and then fix what breaks.

but pushing them to end users vs experienced people first and give
them enough time to report their problems is the key difference.

>
> And if you never are willing to pass something to the users before it is
> 100% stable and tested, then it will never be 100% stable and tested,
> and you simply stop to innovate. But that wouldn't be Fedora anymore
> then.

software is never 100% done or bugfree.  but it appears to me you have
a rather narrow view of only focussing your single system. but that
system has to properly interact with other systems... no matter which
side is to blame.

>
> And I think so far things went really well with systemd, even though
> this discussion might create the impression it didn't.

no it doesent at all. it does create the impression that some people
would rather have a better change management for such critical
components than what it currently appears to be. like stated above...
change management is not about what happens or about gut feeling or
confidence... it is about risk management.

in reality every non technical user wont care if it is systemd or
component xyz which is to blame. if it doesent work it doesent work...
but especially if it worked before they wont see any improvement just
a regression. if a simple text editor fails it is one thing. if a
kernel fails you can still boot an old one (after you figure out how
to display the grub menu...) but if an init system fails it doesent
boot and the conclusion would in most cases probably be that you just
install something else if you dont have enough skills to actually get
it to work somehow or analyze the problem.

Rudolf - also working for Red Hat, Inc.

>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>