+1 At platform we do remove all milestones and release candidates on the release day. According to Photon's final daze https://wiki.eclipse.org/Photon/Final_Daze we are supposed to remove previous milestones and release candidates during RC phase. I propose removal by M1 itself. Thanks and Regards, Sravan Sravan Kumar Lakkimsetti IBM India Pvt Ltd, Embassy Golf Links Business Park, C Block, Off Indiranagar-Kormangla Inner Ring Road, Bangalore - 560071, India From: "Ed Merks" <ed.me...@gmail.com> To: cross-project-issues-dev@eclipse.org Date: 26-08-2021 20:12 Subject: [EXTERNAL] Re: [cross-project-issues-dev] SimRel: retention time for milestone and release candidate repos Sent by: "cross-project-issues-dev" <cross-project-issues-dev-boun...@eclipse.org> +1 I expect that most people with time and diligence remove all milestones and release candidates after a release's GA. On 26.08.2021 15:42, Jonah Graham wrote: ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 26 Aug 2021 at 09:00, Aleksandar Kurtakov < akurt...@redhat.com> wrote: On Thu, Aug 26, 2021 at 3:49 PM Frederic Gurr < frederic.g...@eclipse-foundation.org> wrote: Hi, Are there any good reasons to keep milestone repos, release candidate repos and repos that were replaced with a respin around for an extended time (or forever)? @Jonah: A similar question could be asked for the retention time of EPP milestone and release candidates _repos_. This should not concern the EPP artifacts for milestones and release candidates on the download website. I think there are good reasons to keep the EPP packages around. E.g. the 2018-09 SimRel release contains seven p2 repos (M1, M2, M3, RC1, RC2, and two respins). Only the final release (the last respin) is relevant AFAICT. This would save 10-15GB disk space per release depending on the number of respins. I'd propose that all repos of a release (e.g. 2021-06) are kept until the next final release (e.g. 2021-09) has dropped. Everything except the final release repo (of 2021-06) will then be removed. This would set the retention time to roughly three months. WDYT? +1. Keeping M* and RC* builds is pointless past GA. +1 - to be clear, you can probably reduce the retention time you have proposed. AFAIK Incoming projects (like Platform / CDT) discard M and RC builds just after GA. EPP's retention policy is to only keep releases (repos and full products) after release. I am supposed to do the cleanup on each release, but I sometimes run out of time and clean up multiple releases in one go. It is one of the steps in my release checklist. See "rsync the downloads area to archive.eclipse.org and remove non-R downloads." in https://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/tree/RELEASING.md Jonah Regards, Fred -- Frederic Gurr Release Engineer | Eclipse Foundation Europe GmbH Berliner Allee 47, D-64295 Darmstadt Handelsregister: Darmstadt HRB 92821 Managing Directors: Gaël Blondelle, Mike Milinkovich _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Aleksandar Kurtakov Red Hat Eclipse Team _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
