You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
QuantEcon will review it's lecture hosting and maintenance operations.
@kp992 has shared the following thoughts and ideas:
I had some high-level discussions with Matt yesterday on centralized maintenance and re-using the same workflows to avoid duplication.
Thinking along these lines, I had an idea where we have a repository called lecture-py-store where we keep all python lectures and lecture-py-hpc-store where we keep our lectures that require hardware support. All other series will have a config approach on which lectures to select from the store repo and all the active development happens in the store.
For example,
lecture-py-store is having all the python lectures.
lecture-python series will have a list(toc) of lectures that it needs to show in the series.
It will run some frequency-based syncs like 3 hr or 6 hr to fetch the latest build from the lecture store and render the list of lectures it needs to show.
Benefits of using this approach.
It will be very easy to develop, maintain and keep-uniform styling across all the lectures.
Also avoid duplicating some lectures across several series that are shared currently.
Easy to build new lecture series in future with very minimal setup.
Easy integration and maintenance since we are dealing with single repo. The challenge of syncing Chinese and English lectures will be become relatively easy if we have just one lecture store and need to update just one lecture. The change gets propagated to all the series that lecture is present.
Challenges
The initial setup is hard and a bit time taking but to setup all the workflows and syncing based scenarios.
Investigating how to re-use build from store to series so that we don't waste infra.
Build time can slightly increase but caching will help us here to some extent.
If the syncing cost is negligible we can increase the frequency of sync like 30 mins or 1 hr.
This approach may not be super perfect yet but we can brainstorm and see if we want to move forward with that. How does that sound?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
QuantEcon will review it's lecture hosting and maintenance operations.
@kp992 has shared the following thoughts and ideas:
I had some high-level discussions with Matt yesterday on centralized maintenance and re-using the same workflows to avoid duplication.
Thinking along these lines, I had an idea where we have a repository called lecture-py-store where we keep all python lectures and lecture-py-hpc-store where we keep our lectures that require hardware support. All other series will have a config approach on which lectures to select from the store repo and all the active development happens in the store.
For example,
It will run some frequency-based syncs like 3 hr or 6 hr to fetch the latest build from the lecture store and render the list of lectures it needs to show.
Benefits of using this approach.
Challenges
The initial setup is hard and a bit time taking but to setup all the workflows and syncing based scenarios.
Investigating how to re-use build from store to series so that we don't waste infra.
Build time can slightly increase but caching will help us here to some extent.
If the syncing cost is negligible we can increase the frequency of sync like 30 mins or 1 hr.
This approach may not be super perfect yet but we can brainstorm and see if we want to move forward with that. How does that sound?
Beta Was this translation helpful? Give feedback.
All reactions