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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
