On 19/06/2019 19:27, Brian Stinson wrote: > I deliberately left that unspecified to generate discussion here. The > tradeoff is between keeping large amounts of history, and conserving > space on the mirrors. If we want to prune at point-release time we can. There are a couple of fundamental challenges here, the way we distribute content is a model that was built for an internet and scope which existed in 2001. There is enough infra and wide enough footprint that we should consider moving to a better content delivery model and service, rather than static files, promoted around the world entirely removed from frequency of use or impact. This is going to be a longer conversation, but something we should scope though ( Even if we dont do it. ) retain a small footprint in msync means a more consistent use-case for everyone who needs that content. its a model thats worked well for us, and I'd say worth sticking with - if we were to prune say 2 times a year, past point releases, that would likely work fine. The one problem we -do- need to think through at this point is when folks get stuck across trim lines. eg. kernel running that for a mod build, now needs a src which got trimmed; there is never a good solution for this, other than promoting every vault repo as enabled for all content to be visible, always. regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190624/be44a069/attachment-0008.sig>