search

devopsdays / devopsdays-theme

⛔️DEPRECATED - Hugo theme for devopsdays.org
Other
5 stars 12 forks source link

disambiguate "legacy" vs "static" #609

Open bridgetkromhout opened 6 years ago

bridgetkromhout commented 6 years ago

Expected behavior

Rarely, we need to correct info for old events. I did an update for Minneapolis 2015 which I thought would take effect. It did not. I figured out why: we have a possible area of confusion.

Actual behavior

My update in the legacy repo worked for 2014-minneapolis and had no effect for 2015-minneapolis. I then updated the current repo and it worked. I looked and discovered why: only the "proposals" links are redirected for Minneapolis and many other 2015 events.

Reproduction Steps

Make a change to anything but the proposals for many 2015 events.

Ideas for solution

We have some events in "static" and some in "legacy". Is there a reason we can't have everything in "static"? What is the purpose of "legacy"?

If we have to have "legacy", I think we should decide exactly what is going to be managed from "legacy" and ensure that those files appear only there and not in the main repo. If something isn't managed in legacy, it shouldn't appear there. It's confusing to have the same file appear in both with no clarity as to where it should be edited.

mattstratton commented 6 years ago

the purpose of legacy is the offloaded static files out of the main repo, to keep the repo smaller.

If there are items in static for an event that i partially in static and partially in legacy, that is in error. I think that the migrationof 2015 got messed up. I'll look into it.

Also, when things are migrated to legacy, they should be removed from static in the main repo, but I don't doubt that I've messed that up in the past.

bridgetkromhout commented 6 years ago

Okay, so I think we have some cleanup to do here. I also was hoping we could someday not have to make parts static, but given build times, I don't think that's an option right now.

mattstratton commented 6 years ago

I think with Tim’s improvements, and If we can tweak the program page build, this might be okay.

This has always been more about “Too many open files” on OS X though. I think.