Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Retention time for SimRel releases


On Fri, Nov 19, 2021 at 11:46 AM Christian Dietrich <christian.dietrich@xxxxxxxxx> wrote:

i would like to see better support to maintain e.g. composite updates sites for that.
but with 2 releases i think this is the death to composite updates sites for
multiples releases in general as there is not much to find.

I don't see the relationship here. One can have a composite site with as many versions as they want on downloads pointing to 2 versions from downloads and rest from archive and even have that transparent thanks to redirects (aka no change in the composite site when archiving). The discussion here is what is on downloads (aka mirrored).
 


Am 19.11.21 um 10:43 schrieb Aleksandar Kurtakov:


On Fri, Nov 19, 2021 at 11:37 AM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:


On Thu, Nov 18, 2021 at 7:43 PM Frederic Gurr <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi,

On https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/78
("Download.e.o size too big for mirrors"), Aleksandar Kurtakov pointed
out, that a big chunk of disk space is taken by the content of the
https://download.eclipse.org/releases folder.

It currently contains all SimRel releases from "Europa" to 2021-12
taking up ~100GB. As a first step the mirrors exclude list has been
modified so all releases up to "Mars" are not mirrored.

I'm planning to move all releases from "Europa" to 2019-12 to
archive.eclipse.org next week. So only the last 8 releases will stay on
download.eclipse.org. I will add the task to move old releases to
archive.eclipse.org to the release check list
https://wiki.eclipse.org/SimRel/Release_Checklist.

Please let me know if you have any questions or concerns.

In https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/78 it's written "download.e.o must only contain the last 2 releases. Older releases must be moved to archives". IMHO it would be good if this is either enforced that way for everything(!) or changed to some other number (for which there is agreement it makes sense) and again enforced.

IMHO, such a check should be part of release or progress reviews and actions required from projects. Having smth happening regularly, being well defined and actionable is what we should aim for rather than the current "exclude" lists and generally costing time to people involved in many projects to just go and check if any of the dozens projects involved in is guilty.
 
 

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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Aleksandar Kurtakov
Red Hat Eclipse Team


--
Aleksandar Kurtakov
Red Hat Eclipse Team

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


  





Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann
Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald Goertz, Eric Swehla
Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen (Germany)
Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
_______________________________________________

cross-project-issues-dev mailing list

cross-project-issues-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev




-- 
Aleksandar Kurtakov
Red Hat Eclipse Team


























  Back to the top