On Wed, 2015-11-04 at 20:03 -0600, Michael Catanzaro wrote:
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.
I've been using dnf-automatic with:
apply_updates=True
upgrade_type=security
on Fedora Server for that.
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