Miroslav Suchý wrote: > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a): >> I am really angry at Copr's expiration policy once again. It looks like I >> missed the deadline to renew the expired chroots (I still do not get any >> notification mails, they end up eaten in a spam filter somewhere), so >> once again a lot of data was deleted forever with no way to recover it. > What is your proposal then? The resources are not infinite. At least allow the opt-out per maintainer. I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and then evaluate how many maintainers actually check that checkbox and how much resource usage is actually caused by it. Then after a year or two, decide whether to keep the checkbox or revert to the current status quo. Or drop it sooner if you really run out of disk space as quickly as you seem to expect. >> (By the way, I have since entirely deleted 3 deprecated Coprs that do not >> have builds for newer releases and hence stopped being useful entirely as >> a result.) > ??? If you have enabled "Follow Fedora branching" (per-project setting) > then all your packages are automatically rebuild for new Fedora version > when it is added to Copr. And your project will be always up2date. Patched mesa builds based on an ancient Fedora mesa package are not going to be of any use on current Fedora releases, which is why I had not enabled those autorebuilds for that Copr. I no longer build the nouveau-locking- patched mesa, and in fact, I believe the issue has finally been fixed upstream since, years later. The other 2 repositories were about providing a stable Wesnoth on a Fedora release that shipped with an unstable version, but that stable version is now really outdated (there has been at least one new stable release since), so I deliberately did not support that Copr on current Fedora. But now it is also no longer available for those Fedora releases that I did intend to support. > BTW email is not the only one notification we have. If some of yours > chroot are flagged as EOL you will be shown this banner in WebUI: > > Some of the chroots you maintain are *newly marked EOL*, and will be > removed in the future. Please review > https://copr.fedorainfracloud.org/user/repositories/ to hide this warning. That assumes I actually log into Copr, otherwise I will never see the message. Maybe only start the timer if the maintainer actually logs into Copr and sees the banner? >> PS: At the very least, you could add a checkbox to allow a maintainer to >> opt out permanently of automatic expiration (it would still be possible >> to > > This is not a solution as it does not comes with solution where we get the > storage. I am not convinced that the storage requirements will actually skyrocket as quickly as you expect. As I wrote, I would suggest trying it out and evaluating what happens. >> manually click on "Expire now"), as opposed to having to click dozens of >> buttons (an everincreasing number, since there is not even an "Extend >> all" button) at least every 180 days (in practice, more often, or you end >> up missing the deadline). That is a very unfriendly dark pattern. > > We did not put there "Extend all" intentionally. With the intent that you > have to consider each project separately and think about if you still > really needed. That is exactly the definition of a dark pattern. > BTW: I am curious what is your use-case to keep **dozens** EOL > repositories (which means F34-) alive? A handful Coprs * several EOL releases * several architectures = dozens of buttons to click. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
