On Sun, 7 Nov 2021 at 00:16, Sumit Bhardwaj <sumitkbhard...@gmail.com> wrote: > > It is not always about speed. There are still plenty of places in the world > where people are on limited data plans and to them using delta rpms makes a > lot of sense. They can work with slow speeds but not with high data expenses. > So i feel turning it on by default and having a setting to turn it off is > still a sane choice. Just my 2 cents. >
To me this entire conversation is a tradeoff argument Project issues 1. Having delta rpms allows for groups of people who could not work with Fedora to have some ability to do so on limited data lines. 2. Each broken delta causes frustration and various 'why does this tech suck' emails/irc pings/discussion threads which eats energy from volunteers. Infrastructure issues 1. The build infrastructure is a limited resource with limited disk space, cpu, and a goal of composing updated artifacts for consumption at least once a day. 2. Each delta takes disk space on our download and mirror system which is also a limited resource. Infrastructure can only do deltas between N package deltas 3. Each delta uses a large amount of compression which takes a long time/energy on the servers to generate. This slows down the ability to produce artifacts. Consumer issues 1. Each delta can save the consumer download times on their limited resource 2. Each delta uses a large amount of compression which means that applying on low power devices can be much slower than just downloading the entire package. 3. Because Fedora composes at least once a day, consumers require constant downloads to Fedora so that they can get 'working' deltas. Only download once a week, and find that the downloaded deltas aren't useful. Does having to download deltas every day outweigh the savings of the deltas? How does one measure that? How does one know what packages deltas make sense for and how many of them need to be generated? -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
