Re: Copr delete-by-default expiration policy still unacceptable
On Fri, Oct 14, 2022 at 09:24:05AM +0200, Miroslav Suchý wrote: > Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): > > 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. > > I will discuss this with the team. > > History lesson: > > in past, we did not deleted old repos. And it was on user to delete it. > And almost **nobody** clean up their repos. That is entirely predictable behaviour, seen by almost free service which doesn't have usage limits. When all the cost pressures fall on a 3rd party there is no incentive for people to moderate their usage, whether it be CPU burn, storage usage, network bandwidth, or something else. Any free service will almost inevitably end up imposing policies to control usage in areas where they're feeling the greatest burden, once their funding starts to look unsustainable, or the sponsoring orgs' priorities change. For storage it either ends up with old stuff being force deleted, or users accounts get finite quota applied as a means to force users to delete stuff themselves past a certain point, or both, depending on the usage patterns seen. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 16:24 Josh Boyer napsal(a): Would you be willing to pay for that feature? BTW I have been seriously probing for some time whether people would be willing to pay for private repositories. And this is my first time mentioning it in public space :) Miroslav ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 17:18 PGNet Dev napsal(a): Another option is to get the containerized COPR efforts polished & available. Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, &/or make available ... and, charge some reasonable fee for those downloads. https://pagure.io/copr/copr/pull-request/2193 Miroslav ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): 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. I will discuss this with the team. History lesson: in past, we did not deleted old repos. And it was on user to delete it. And almost **nobody** clean up their repos. Miroslav ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 15:27 Stephen Smoogen napsal(a): The problem is that they HAVE been running out of disk space quite regularly. This is not a new problem as COPR has bounced off of zero storage over time as various 'newer' hardware is moved over for their usage. Currently, the storage they are using is an aging disk service which will go out of warranty in about a year. This is situation we used to have. Nowadays we use a storage from AWS (we are grateful for their sponsoring). And we got it for free. The problem is that we just hit a glass ceiling of this unlimited service as you cannot create volume larger than 16 TB. Last month we spent some time investigating the options (EFS, RAIDs) and we decided to use RAID of several volumes. We have a WIP blogpost about this. The problem is not money right now, but maintainability. E.g., it take **days** to sync the volumes. And it took us two weeks of preparation to prepare for migration (which will happen in few days and is about to be announced) which will last just few hours. Miroslav ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 17:06 Neal Gompa napsal(a): Considering services like packagecloud.io and others exist and do manage to make money storing repositories and builds, I think it's pretty workable for COPR too. It would require some advertising and such to get it out there, but it'd be workable. What about connectors for this package hosting services. I.e. you would be able to configure Copr to upload sucessfull builds to your hosting repository. If you would find this usefull and you would use this, please leave your comment here https://pagure.io/copr/copr/issue/2342 Miroslav ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 3:56 PM Josh Boyer wrote: > > On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster > wrote: > > > > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer > > wrote: > > > > > Would you be willing to pay for that feature? > > > > A "freemium" COPR service? > > > > I suspect that that would be such a > > niche service that the cost per user > > (to pay for the overheads to create > > and maintain it) would not be > > acceptable to anyone. > > I find that statement to be... ironic. We're already running a free > COPR service and paying for the overhead to create and maintain it. I was talking about adding the "freemium" paid service, which means being able to charge users. Adding in the various payment processing options (and terminating service when payment ends) is typically complex. Real money changes everything. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster wrote: > > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote: > > > Would you be willing to pay for that feature? > > A "freemium" COPR service? > > I suspect that that would be such a > niche service that the cost per user > (to pay for the overheads to create > and maintain it) would not be > acceptable to anyone. I find that statement to be... ironic. We're already running a free COPR service and paying for the overhead to create and maintain it. josh ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Don't get me wrong, the folks who work on Koji and Copr are great, but even they'll admit that they're woefully underfunded. The compose tooling, PDC, etc. are also examples of this problem. Can't agree enough. Hats off to the COPR folks. Without it, even it current state, RH/Fed ecosystem is, at least here, a LOT less tenable/attractive, if at all. Even in a world where I would be *able* to pay for it (and there's plenty of commercial evidence that such a service would be something people would pay for), I just don't think it would stick. Here's 1 'mid-sized umbrella' vote. I'm happy to pay for a COPR service. Particularly if it were to exist on at-least-arm's-length infrastructure, and provides decoupling from RH/IBM's corporate legal paranoias and policies. That could be managed as reasonable subscription fees. Another option is to get the containerized COPR efforts polished & available. Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, &/or make available ... and, charge some reasonable fee for those downloads. And by reasonable fees, I'm not talking about Enterprise-sized profit-generating-fees, but enough given Fedora-project's real needs (devs & infrastructure) to defray, at least some of the, operating costs. And something that a significant majority of current contributors -- paid & volunteer alike -- would consider a worthwhile bargain for the value received. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster wrote: > > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote: > > > Would you be willing to pay for that feature? > > A "freemium" COPR service? > > I suspect that that would be such a > niche service that the cost per user > (to pay for the overheads to create > and maintain it) would not be > acceptable to anyone. Considering services like packagecloud.io and others exist and do manage to make money storing repositories and builds, I think it's pretty workable for COPR too. It would require some advertising and such to get it out there, but it'd be workable. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote: > Would you be willing to pay for that feature? A "freemium" COPR service? I suspect that that would be such a niche service that the cost per user (to pay for the overheads to create and maintain it) would not be acceptable to anyone. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Il 13/10/22 16:48, Kevin Kofler via devel ha scritto: > > What makes Copr so interesting is that it is offered at no cost to all > Fedora contributors. But it has always been treated as an unloved stepchild > by Red Hat and has never received the kind of resources, e.g., OBS has. Is there any chance Fedora can put some money for that? Who is responsible for spending Fedora resources? Looking at the Fedora budget summaries [0] (latest available is for 2020...) Fedora always closes years spending only 50% of the available budget... can't we put some money on technical stuff needed by the platform instead of always rely on RH? [0] https://budget.fedoraproject.org/budget/docs/index.html ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel wrote: > > Josh Boyer wrote: > > Would you be willing to pay for that feature? > > Probably not, because at that point, it would probably be cheaper to just > set up a mirror or even a full-fledged build system on a VPS somewhere. Or > even to use OBS, though I do not know what their retention policies for old > repositories are (i.e., whether they are any better or even worse). > > What makes Copr so interesting is that it is offered at no cost to all > Fedora contributors. But it has always been treated as an unloved stepchild > by Red Hat and has never received the kind of resources, e.g., OBS has. > Though it is still better than what smaller distributions like Arch are able > to offer, where, e.g., the AUR only allows publishing the source PKGBUILD > files and no binaries at all. > Red Hat has not truly invested in Fedora build infrastructure software in a long time. It's pretty clear they don't consider it valuable enough to have a significant team supporting it like SUSE does for their stuff. Don't get me wrong, the folks who work on Koji and Copr are great, but even they'll admit that they're woefully underfunded. The compose tooling, PDC, etc. are also examples of this problem. Even in a world where I would be *able* to pay for it (and there's plenty of commercial evidence that such a service would be something people would pay for), I just don't think it would stick. This is also part of the reason why I'm extremely wary about their desire to hotwire Fedora image builds into the Red Hat hosted image builder infrastructure. I've seen this story repeat so many times now that I distrust new efforts from them on this front now, because we always wind up holding the wet paper bag in the end. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel wrote: > > Josh Boyer wrote: > > Would you be willing to pay for that feature? > > Probably not, because at that point, it would probably be cheaper to just > set up a mirror or even a full-fledged build system on a VPS somewhere. Or > even to use OBS, though I do not know what their retention policies for old > repositories are (i.e., whether they are any better or even worse). Ok. Then perhaps you should pursue the mirror idea to solve your needs. Putting that into a cloud storage bucket seems like it would give you what you want. > What makes Copr so interesting is that it is offered at no cost to all > Fedora contributors. But it has always been treated as an unloved stepchild > by Red Hat and has never received the kind of resources, e.g., OBS has. > Though it is still better than what smaller distributions like Arch are able > to offer, where, e.g., the AUR only allows publishing the source PKGBUILD > files and no binaries at all. Yes, COPR is great. But "indefinite storage" or "user defined storage" is not a core tenant of what it is for. Keeping it free while iterating on useful features requires limitations elsewhere. To be clear, I am in no way suggesting COPR should ever move to a paid-for model. I'm just highlighting that it's a free service that has operating costs and budget and it is reasonable to limit that in some ways. josh ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Josh Boyer wrote: > Would you be willing to pay for that feature? Probably not, because at that point, it would probably be cheaper to just set up a mirror or even a full-fledged build system on a VPS somewhere. Or even to use OBS, though I do not know what their retention policies for old repositories are (i.e., whether they are any better or even worse). What makes Copr so interesting is that it is offered at no cost to all Fedora contributors. But it has always been treated as an unloved stepchild by Red Hat and has never received the kind of resources, e.g., OBS has. Though it is still better than what smaller distributions like Arch are able to offer, where, e.g., the AUR only allows publishing the source PKGBUILD files and no binaries at all. Kevin Kofler ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
You do have to admit that this happens only as a result of: - wanting to support EOLed chroots - not wanting to support non EOLed chroots (for those projects) - not receiving notification e-mails - not logging onto the web UI for more than 75 days All of this in combination, and knowingly, as you write. I think it's quite a lot to ask for a change to cater for that specific combination, rather than adjusting your mail filters or habits. COPR is a great free service, repos are left rotting all the time for various reasons, and the way the cleanup is done supports keeping COPR available for free (to us). ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, Oct 13, 2022 at 8:41 AM Kevin Kofler via devel wrote: > > 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. Would you be willing to pay for that feature? josh ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
On Thu, 13 Oct 2022 at 08:49, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > 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. > > The problem is that they HAVE been running out of disk space quite regularly. This is not a new problem as COPR has bounced off of zero storage over time as various 'newer' hardware is moved over for their usage. Currently, the storage they are using is an aging disk service which will go out of warranty in about a year. As far as I know, there is no budget to buy more disk space for this project. Instead there is a long list of complaints from the community which usually get aggregated up as 'this is not working, why do we still invest in it?' -- Stephen Smoogen, Red Hat Automotive 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
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@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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
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. (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. The assumption that users will receive notifications mails and act on them is still entirely invalid (because e-mail is not a certified delivery method, mails can get lost at any time), and deleting data is not and will never be a safe default. The default must be to retain, not to delete. 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. 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. 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. BTW: I am curious what is your use-case to keep **dozens** EOL repositories (which means F34-) alive? Miroslav___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
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 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. Kevin Kofler ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Copr delete-by-default expiration policy still unacceptable
Hi, 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. (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.) The assumption that users will receive notifications mails and act on them is still entirely invalid (because e-mail is not a certified delivery method, mails can get lost at any time), and deleting data is not and will never be a safe default. The default must be to retain, not to delete. Kevin Kofler ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
