Re: Schedule for Monday's FESCo Meeting (2012-06-18)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jun 17, 2012 at 8:19 PM, Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote:
> On Sun, Jun 17, 2012 at 2:08 PM, drago01 <drago01@xxxxxxxxx> wrote:
>> A new feature is being added nothing is getting removed so no there is
>> no regression.
>
> Thats newspeak if I ever saw any.
>
> Going from a system which generally doesn't prompt users to reboot to
> one that does is a regression.
>
>> dbus is not optional. Not including it would mean throw out half of the distro.
>> And no idea what that has to do with systemd either.
>>
>> Randomly blame stuff does not help your point.
>
> I was not "randomly blaming" I was copying from Richard Hughes
> message.  He said these services need system reboots for upgrades.
> "That isn't what we signed up for"

Yeah but those where examples not the sole reason why reboots are required.
 It is not like if we didn't switch to systemd this problem wouldn't
exist. (which was my point re "blaming").

>> I am not seeing any bad effects here ... I am seeing a feature
>> proposal that tries to solve a problem that you dismiss as non
>> existent while it is.
>
> I haven't personally experienced problems with this but I trust that
> there are problems.  Causing users to need to reboot for updates does
> not solve the problem— it masks it.  And masking can be a fine
> "solution" where its harmless, but it certainly isn't here.  The
> reboot for upgrades stuff in windows is one of the most often cited
> annoying anti-features, so it's understandable why people would throw
> stones at something that looked like it was emulating it.

Sure but then suggest alternatives just doing nothing is not a
solution either.  This feature also allows updates to be applied in a
well defined state and use btrfs snapshots to make sure that
everything works even if the upgrade got aborted by a crash, power
failure etc. (rpm transactions are not ACID so you end up in an
undefined state in that case).
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux