RFC - Older event archiving

[nimbinatus]

What if events were archived as a summary page that listed the talks with speakers, abstracts, and video links if available (no speaker pictures); the sponsors and their links (no logos), the organizers (no pictures), and the general date/time/location info? That would significantly cut down on overhead as we consider how to reset the site architecture, gets rid of the sponsor logo drama, stops preserving data people don't need like old prospectus pages, etc etc etc. Not sure what historical or current gotchas there are in there, but I could easily see a manual job trigger that we could run once a year that took that data and condensed it for events older than, say, three years.

[mattstratton]

note that moving to this would actually require some non-trivial surgery as a lot of the older events not longer exist in the repo as .md files, so converring them would require restoring an older version of the repo prior, etc (I've done this for some other things in the past, so it's not insurmountable, but you won't be able to really "test" it going back much further than 2019 i think)

[nimbinatus]

Oh, 100%, and I think the time to do this kind of thing is when we do move to the new structure anyway. The lift is already something planned, in that case.

[mattstratton]

that said, this helps in a lot of ways bc also ensures that google's cache, etc, doesn't point to pages that are not useful (and potentially confusing) like sponsor pages, etc, fromyears and years ago

[don-code]

Not disagreeing with the idea, but I'm wondering how much it would save us. The archived events (currently anything before 2018) have all of the "heavy" assets moved to the CDN as of #13018, and their contribution to the repo is a paltry:

[don@zeus ~/devopsdays-web/static/events:main] echo $(find . -maxdepth 1 -type d -regextype egrep -regex './201(1|2|3|4|5|6|7|8).*' | xargs -i du -h -d 0 {} | awk '{print $1}' | sed -r -e 's/M//' -e 's/(.*)K/0.\1/' -e 's/$/ +/' | tr '\n' ' ' | sed 's/...\{1\}$//') | bc
140.6748

megabytes, which on a 9.3GB repo seems kind of inconsequential. If there's a higher cost at devopsdays-assets to keeping those extra files, I'm definitely on board there.

(That was a fun project for my train ride home!)

[nimbinatus]

Ahhh, different reason I want to do it! I should have been clearer. It's more about site maintenance/process overhead rather than file sizes/physical overhead. If we didn't have to, say, update the sponsor logos all over the place, then we reduce the need to go through that whole process.

[jerdog]

This makes sense as I was also thinking about the repo size overhead instead of the process.