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

On Sun, Jun 17, 2012 at 05:06:51PM +0100, Richard Hughes wrote:
> On 17 June 2012 10:53, Richard W.M. Jones <rjones <at> redhat.com> wrote:
> > So this is a problem that needs to be solved, but does it require a
> > reboot?  Not really ... it's possible to list all processes using
> > zlib, convert that back into a list of packages, then instruct those
> > packages to restart themselves.  Job done, BETTER than Windows / OS X.
> 
> That's simply not possible. Some processes like dbus-daemon and
> gnome-session just cannot be restarted in this way.

You're asserting that dbus-daemon etc cannot be restarted, but without
saying why.  The current design may make restarting some daemons
difficult but we should fix those problems.

If you want to look around for ideas to lift from other OSes, take a
look at:

 - QNX
 - z/VM
 - EROS

Some of these OSes can run virtually indefinitely, being upgraded all
the time as they go along.  So please don't tell me that it's "simply
not possible".  It might not be possible *with poorly designed Linux
daemons* but that's quite a different thing.

[More assertions without explanations snipped]

[Irrelevant comment about static linking snipped]

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

On Sun, Jun 17, 2012 at 12:06 PM, Richard Hughes <hughsient <at> gmail.com> wrote:
> That's simply not possible. Some processes like dbus-daemon and
> gnome-session just cannot be restarted in this way. It's a complete
> fallacy to believe you can update core libraries on a modern Linux
> system without rebooting.

I upgraded running systems from a.out to elf and from libc to glibc
without shutting down.

Okay, init itself is a bit tricky, but it also basically does nothing
on a running system so the problems in upgrading it are not especially
relevant.

And now some mere userspace daemons mean users will constantly need to
reboot for upgrades?

Regressions against featuresets from the '70s and '80s are pretty unfortunate.

This is starting to sound like evidence of a serious design flaw in
some of these daemons. I find that unfortunate because I really like
systemd.

(And the "you can manually force it", seems not much of a consolation
to me— since that will be untested, unsupported, and very likely
non-functional.)

If we ask the question— retrospectively, if we knew that eventually
the acceptance of systemd (or newer dbus-daemon) would have ultimately
resulted in needing to reboot for updates would we have accepted it?
I think the answer is pretty clearly No.

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

On 06/17/2012 06:06 PM, Richard Hughes wrote:
> On 17 June 2012 10:53, Richard W.M. Jones<rjones <at> redhat.com>  wrote:
>> So this is a problem that needs to be solved, but does it require a
>> reboot?  Not really ... it's possible to list all processes using
>> zlib, convert that back into a list of packages, then instruct those
>> packages to restart themselves.  Job done, BETTER than Windows / OS X.
>
> That's simply not possible. Some processes like dbus-daemon and
> gnome-session just cannot be restarted in this way. It's a complete
> fallacy to believe you can update core libraries on a modern Linux
> system without rebooting. Add btrfs snapshotting to the mix (to be
> able to do updates safely) and doing updates in-situ becomes
> impossible. If Fedora wants to statically link everything, then it's
> certainly possible to workaround, but that's not acceptable to Fedora
> for perfectly understandable reasons.

I wonder if it would be possible to do it on shutdown instead of during 
start up? I usually do not care if shutdown takes ten seconds or five 
minutes, but when I start my computer I do so because I want to use it 
and not wait several minutes before its ready.
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

On Mon, Jun 18, 2012 at 12:09 PM, Lennart Poettering
<mzerqung <at> 0pointer.de> wrote:
> I mean, have you ever tried to upgrade firefox while running firefox? If
> you did, you know how awfully wrong that goes... [1]

I run Mozilla's nightly builds and receive updates every day. They
disrupt nothing because Mozilla has built infrastructure to make that
possible. Firefox must be restarted for the updates to take effect,
which is when it does the actual swapout of the staged files, but the
restart is basically just a window flickering— tabs retain their
state, including forms— in fact to prove the point I manually
triggered it while writing this email.

This is the direction Fedora should be heading in, if not quite as
non-disruptive as what firefox does... and it's not that far off
because with the exception of the recently written desktop
infrastructure the system largely already support non-disruptive
updates. By making updates regularly require reboots the incentive to
bridge the gap is reduced and the expectations of a clean enviroment
will increase until a rebootless update is as inconceivable in Fedora
as it is in Windows.

By making updates regularly require reboots you put users in an
adversarial relationship with updates. Rather than being seen as
something that helps them, updates will be seen as something that get
in their way. Many will turn them off completely if you give them an
option to do so.  We don't have to speculate about the long term
consequences of this path because we can already see it in the Windows
world: e.g. On several occasions I have seen windows update disrupt
presentations because the speaker was talking to the audience and

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

Am 18.06.2012 18:09, schrieb Lennart Poettering:
> I mean, have you ever tried to upgrade firefox while running firefox? If
> you did, you know how awfully wrong that goes... [1]
> 
> So, you have three problems: a) you cannot safely determine what to
> restart. b) you cannot restart many components of the OS at all c)
> upgrades cannot be atomic.

i even did DIST-UPGRADES while Firefox, Thunderbird, the whole KDE
and Eclipse where up and running without issues

only while KDE parts get updated the start of a NEW instamce of a
kde-app (as example kate) fails but there was never a problem with
running applications

and now you come the road and thell us firefox can not be
updated while it is running? strange that i apply FF updates
since years in my daily workload and after all are finished the
browser get's restarted or even at the next day if the update
happens 1 or 2 hours before i go home

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]

Jóhann B. Guðmundsson wrote:
> First and foremost each SIG sets and choose what is on the spin they
> ship so if you dont want to ship the bloat that gets added with the
> "MiniDebugInfo" then simply don't atleast afaik now there is nothing
> forcing spins to ship something that they don't want to.

How would you suggest we implement this? rm -rf the stuff in %post? 
(Yuck!!!) As I understand it, the symbols will be bloating the main packages 
and not be in subpackages. (Debuginfo subpackages are what we have now.)

> With my QA hat on I can tell you that we test components that make up
> the spin(s) but do not care anything about the size of the spins nor
> should we since as I said before that decision should be made/handled by
> the SIG since they are the ones creating the spins to suit *their*
> target audience as best as they can.

The target size is one of the release-blocking criteria you're supposed to 
validate.

        Kevin Kofler

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]

----- Original Message -----
> As far as QA is concerned it's entirely your decision (as a personal
> note to self, I'll have to update the Deliverables SOP draft). We
> just
> need to know so we know what limit to check against in testing.
> 
> As a personal comment, though, doesn't this seem a little fast to
> make
> the decision? Wouldn't it at least make sense to wait for
> minidebuginfo
> to be implemented, then spin a test KDE image and see exactly how big
> it
> turns out with the current package set? Note that spins are not
> absolutely required to hit their target size at Alpha; it becomes a
> hard
> requirement at Beta stage. So you have up until Beta release to make
> the
> decision, really.

The reason why we start *talking* about it now is that we are quite sure
it's going to a problem for the KDE spin. As QA you know that we are
on the edge of current size limit with every release - we already did
a lot of compromises and with every release more and more stuff is 
pulled into the image :( So MiniDebugInfos aren't the only problem,
just a kick off to move on :)

R.

> --

Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]

Adam Williamson wrote:
> As a personal comment, though, doesn't this seem a little fast to make
> the decision? Wouldn't it at least make sense to wait for minidebuginfo
> to be implemented, then spin a test KDE image and see exactly how big it
> turns out with the current package set?

We will have to check what size we hit exactly (my guess is something 
between 700 and 800 MiB, which is why we're discussing an 800 MiB target), 
but what we know is that F17 was at 695 MiB, and the numbers the 
MiniDebugInfo feature page is quoting are way above the 5 MiB we have left. 
(And in addition, those 5 MiB are likely to be taken up by other creeping 
bloat. Everything just gets larger and larger at every release, usually 
without anything concrete to pinpoint.)

So it is not possible to ship a KDE spin with MiniDebugInfo without 
increasing the size target, dropping some applications or both.

        Kevin Kofler

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 20 Jun 2012 17:10:08 -0500
Dennis Gilmore <dennis <at> ausil.us> wrote:

> El Tue, 19 Jun 2012 12:19:35 -0400 (EDT)
> Jaroslav Reznik <jreznik <at> redhat.com> escribió:
> > As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG
> > meeting that we would have to break CD size limit (and the breaking
> > of CD size image was used as argument to accept this feature).
> > 
> > We agreed that 800 MiB is achievable target:
> > - all spins will still fit Multi Desktop Live DVD
> > - there's still space available for overlay for USB disks
> > - you can still get 800 MiB CD-Rs (may hit HW constraints...)
> > 
> > Other possibility is to go directly to 1 GiB but we are not sure
> > there's advantage (at least not now).
> > 
> > Contingency plan - at least for one release we'd like to have a 
> > 700 MiB KS (with more compromises).
> > 
> > So we'd like to hear from rel-engs, QA etc. what's theirs position
> > here.
> 
> from Relengs perspective it doesnt matter what size it is. so long as
> it meets the release criteria then its ok. 
> 
> Personally i have a serious concern over dropping cd sized media. One

Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)

On Tue, Jun 19, 2012 at 8:30 AM, Thorsten Leemhuis <fedora <at> leemhuis.info> wrote:
> Josh Boyer wrote on 19.06.2012 13:42:
>> On Tue, Jun 19, 2012 at 5:09 AM, Till Maas <opensource <at> till.name> wrote:
>>> On Mon, Jun 18, 2012 at 01:10:34PM -0600, Kevin Fenzi wrote:
>>>> * ticket 864 F18 Feature: DNF -
>>>>   https://fedoraproject.org/wiki/Features/DNF  (nirik, 17:44:17)
>>>>   * AGREED: Feature is approved (+8/0)  (nirik, 17:56:59)
>>> It would help a lot if a features are only approved, when they have
>>> descriptive names. From the message above it is completely unclear what
>>> was approved. But if the feature was named like for example "DNF package
>>> manager preview" there would be at least some information about what the
>>> DNF features is supposed to be.
>> Because you can't click on the link and read about the feature where
>> it describes this in detail?
>
> You can, but immediately getting the most relevant information makes
> life a bit easier for those on the receiving side. That is a nice
> gesture and shows that you value the time and interest of the readers.
> For afaics similar reasons most people here (you including) trim email
> replies and reply inline, as that makes communication a little bit
> easier, which is nice in these hectic times.

That's fine.  I don't consider it something required for approval
though.  It's at best a filter so people don't click links they don't
find interesting.

josh
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org