Updates (was Fedora 23 Final RC10 status is GO !)

[Michael Catanzaro]

On Thu, 2015-11-05 at 02:16 +0100, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > 1) More time to catch regressions
> 
> In theory. In practice, it mostly means more wasted time until a
> regression 
> is FIXED, i.e., it is entirely counterproductive. Many regressions
> are only 
> noticed once the update goes stable, because that's when most users
> start 
> trying it.

I think we would need an alternate "fast path" for updates, in case of
regressions. I agree with you that the current karma system hurts more
than it helps there. It should be possible to push an update that
merely reverts a previous update directly to stable.

> I don't see how even longer delays in testing would help. The
> majority that 
> does not have updates-testing enabled won't get it before it goes
> stable no 
> matter how long it sits in testing. The users who use updates-testing
> are 
> those who want updates fast and so will get it within the first
> couple days.

In practice, I've seen bugs caught in updates-testing, and others
caught only after entering stable. More time in updates-testing can
only reduce regressions that make it to stable, but yes, also delay
fixes that we would wish to release sooner. I suspect the ideal amount
of time spent in testing is "more than we do now."

But since you pointed out that service packs could be implemented on
the existing updates system, I'm now leaning towards keeping everything
we have now the same, and using the stable updates repo as a level of
testing for service packs released to Workstation users via GNOME
Software. (You could still get all the latest updates with dnf if you
want.)

> I don't see how a huge mix of unrelated updates is in any way easier
> to QA 
> than the individual small, targeted updates. In fact, I think it is
> the 
> exact opposite: there is no way to adequately QA the whole service
> pack, it 
> just does not scale.

Well yes, it would be worse if we got rid of the karma system and no
longer QAed individual updates, but we should layer our release QA on
top of the updates we do now. After an update graduates from testing,
it'll be automatically included in the next service pack. Then every,
say, six weeks, we do the normal release validation on it and release
updated install media. If it doesn't pass release validation, then
quality has decreased since the initial release and we know there's a
problem with our updates.

> > 3) Less-frequent updates
> 
> That is a BAD thing. I want to get my bugfixes as quickly as
> possible. (In 
> fact, I'm unhappy that our infrastructure does not support instant
> pushes.) 
> I have Apper set to check for updates hourly because the default
> daily is 
> too slow for me! Sure, we don't have hourly pushes (sadly), but daily
> means 
> up to an ADDITIONAL day of delay.

Ah, but while you like this for yourself, I think that is too fast for
the common user.

Maybe you're right, though. The frequency that we release updates
itself isn't necessarily the problem, so much as the frequency the tool
checks for updates. We shouldn't have weekly LO updates by *default*,
but that shouldn't stop you from getting them if you want them. Maybe
we should just configure GNOME Software to check for updates less
frequently, and apply only the security updates and no other update
when there is a security issue. Or do service packs and not worry about
it.

Either way allows us to achieve slower updates for Workstation without
slowing things down for you.

> The negative effect that the whole thing hits at once would be the
> much more 
> noticeable effect. So the updates would actually feel slower, and
> probably 
> even BE slower because the mirrors would be swamped, just as they are
> on a 
> release day.

True, that is a risk... but I think it is less an exception than you
believe. I notice most package updates are for packages that were
updated quite recently. I speculate that a small portion of packages in
the distro make for a fairly large portion of updates, and that service
packs won't balloon to be as large as you expect. Regardless, they
shouldn't be as bad as a post-install update is now, which take 30-45
minutes for me. Install media respins will fix that.

But yes, you're right in that we have a trade-off between frequency of
updates and duration of updates. We have less total time spent updating
if updates are further apart, as updates that would otherwise be
applied separately are obsoleted by newer updates, but more total time
spent in each individual update.

> As for bandwidth-limited users, what would REALLY be a massive
> disaster is 
> your "service pack" approach! If even just LibreOffice alone is a
> problem, 
> imagine all updates of the whole month at once!

People are generally are charged by the month, right? So ensuring each
package is updated at most once per month can only reduce the fees.

> Of course, the contention point is then what is a "core system
> application". 
> If you mean things like LibreOffice, well, that is exactly the kind
> of 
> application that updating would make MOST users happy (and in fact, I
> consider the current update policy for LibreOffice to be way too 
> conservative, it is essentially never updated to a newer upstream
> release 
> series, unfortunately).

No, LibreOffice is not a core system application. I'm talking things
like Files, Videos, System Monitor, System Settings, Terminal....

> What browser do you have issues with?
> Epiphany? 
> Midori? It's strange because webkitgtk should really work if QtWebKit
> works.

Epiphany. I wouldn't use Midori since that uses an obsolete version of
WebKitGTK+ that hasn't been getting security updates for a long time.

I actually like the new Bodhi UI quite well, and don't care that it
requires JS, but I do wish it worked....

Michael