I am using Rawhide, so I personally don't care. But anyway, why don't we have "updates-testing", "updates-batched" and "updates" repositories? "updates-batched" could be enabled by default while "updates" could be enabled manually if one wishes. Vít Dne 17.2.2018 v 23:15 Zbigniew Jędrzejewski-Szmek napsal(a): > Bodhi currently provides "batched updates" [1] which lump updates of > packages that are not marked urgent into a single batch, released once > per week. This means that after an update has graduated from testing, > it may be delayed up to a week before it becomes available to users. > > Batching is now the default, but maintainers can push theirs updates > to stable, overriding this default, and make the update available the > next day. > > Batching is liked by some maintainers, but hated by others > Unfortunately, the positive effects of batching are strongly > decreased when many packages are not batched. Thus, we should settle > on a single policy — either batch as much as possible, or turn > batching off. Having the middle ground of some batching is not very > effective and still annoys people who don't like batching. > > To summarize the ups (+) and downs (-): > > + batching reduces the number of times repository metadata is updated. > Each metadata update results in dnf downloading about 20-40 mb, > which is expensive and/or slow for users with low bandwidth. > > + a constant stream of metadata updates also puts strain on our mirrors. > > + a constant stream of updates feels overwhelming to users, and a > predictable once-per-week batch is perceived as easier. In > particular corporate users might adapt to this and use it to > schedule an update of all machines at fixed times. > > + a batch of updates may be tested as one, and, at least in principle, > if users then install this batch as one, QA that was done on the > batch matches the user systems more closely, compared to QA testing > package updates one by one as they come in, and users updating them > at a slightly different schedule. > > - batching delays updates of packages between 0 and 7 days after > they have reached karma and makes it hard for people to immediately > install updates when they graduate from testing. > > - some users (or maybe it's just maintainers?) actually prefer a > constant stream of small updates, and find it easier to read > changelogs and pinpoint regressions, etc. a few packages at a time. > > - batching (when done on the "server" side) interferes with clients > applying their own batching policy. This has two aspects: > clients might want to pick a different day of the week or an > altogether different schedule, > clients might want to pick a different policy of updates, e.g. to > allow any updates for specific packages to go through, etc. > > In particular gnome-software implements its own style of batching, where > it will suggest an update only once per week, unless there are security > updates. > > Unfortunately there isn't much data on the effects of batching. > Kevin posted some [2], as did the other Kevin [3] ;), but we certainly > could use more detailed stats. > > One of the positive aspects of batching — reduction in metadata downloads, > might be obsoleted by improving download efficiency through delta downloads. > A proof-of-concept has been implemented [4]. > > Second positive aspect of batching — doing updates in batches at a > fixed schedule, may just as well be implemented on the client side, > although that does not recreate the testing on the whole batch, since > now every client it doing it at a different time. It's not clear though > if this additional testing is actually useful. > > There's an open FESCo ticket to "adjust/drop/document" batching [5]. > That discussion has not been effective, because this issue has many > aspects, and depending on priorities, the view on batching is likely to > be different. FESCo is trying to gather more data and get a better > understanding of what maintainers consider more important. > > Did I miss something on the plus or minus side? Or some good statistics? > Does patching make Fedora seem more approachable to end-users? > (this is a question in particular for Matthew Miller who pushed for batching.) > Do the benefits of batching outweigh the downsides? > Should we keep batching as an interim measure until delta downloads are implemented? > Should dnf offer smart batched updates like gnome-software? > Should we encourage maintainers to allow their updates to be batched? > > [1] https://github.com/fedora-infra/bodhi/issues/1157, > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/UDXVXLT7JXCY6N7NRACN4GBS3KA6D4M6/ > [2] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/B6MMH3L36A2YXQ45Y4DUGMR4XIG7QKE5/ > [3] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/F36YMWKDXBHAQWQOLDSYLYTMDF4WYHE6/ > [4] http://lists.rpm.org/pipermail/rpm-ecosystem/2018-February/000534.html > [5] https://pagure.io/fesco/issue/1820 > > Zbyszek > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
