Topics

• Is there a benefit to having edx.org theme in edx-platform? We can move it to https://github.com/edx/edx-themes with almost no effort I believe (I’ll be there for the second half of the meeting -Matt)

  • Currently in platform under themes/edx.org

  • Philosophically, should probably be moved. Logistically, it might be easier for us to leave it where it is.

  • Community has expressed the sentiment that we should deal with themes the same way we have to.

  • We’d have to figure out how to move it while minimizing risk to edx.org

  • Another downside:

    • edX devs would also have to pull down and set up edx-themes

  • We’ve already been doing this for whitelabel

• Will we split up LMS and Studio eventually?

  • That’s the hope!

  • Will we do it? Maybe eventually…

  • Is a useful “north star” to have in mind when working in the monolith.

  • What is stopping us?

    • Imports from CMS to LMS and vice-versa

    • Shared database

    • Django Signals - we expect them to be in-process.

    • edx-platform is not installable

      • Cale: “It has a setup.py, so it’s theoretically installable.”

    • We have talked about actually just duplicating edx-platform, and then LMS and CMS repos would each individually what they don’t need over time.

    • Alternatively, we could pull out openedx/common into edx-core.

      • Would be difficult.

    • What value would we see out of doing this?

      • Smaller codebase → smaller test run time

      • Independent deployments

      • Approachability - A smaller codebase is easier to learn, comprephend, make statements and assumptions about.

      • Cale: Splitting it into two repos doesn’t necessarily make it simpler

• How could we speed up edx-platform tests?

  • We have more shard capacity due to the removal of bok choy - maybe we should turn that knob

  • We use setUp where we could use setUpTestData quite a lot.

    • setUpTestData is like setUpClass, except that you can modify the database in a test method, and it will get rolled back.

    • Dave: Modulestore operations & cascading signals may be a larger issue.

    • Pytest profiling: https://github.com/man-group/pytest-plugins/tree/master/pytest-profiling

  • Feanil: Are tests slowing down developers?

    • Cale: It’s pretty uncommon for devs to run tests in edx-platform locally, unless they’re adding new tests. So, they end up shipping it off to CI.

      • who-tests-what could be helpful here.

    • Cale: What he sees slowing down devs is the sheer conceptual weight of LMS

      • It’d be good to separate tricky stuff (xmodule, etc) from day-to-day Django REST-endpoint-esque things

• Cale: If we were to extract everything required to render xblocks into its own plugin, how could we do that?

  • Dave: The runtime services are pretty tightly coupled with edx-platform

  • The purpose of this would be to stop normal, dumb LMS Django code from querying the modulestore, or doing other hairy things that slow the site down.

  • Dave: The direction we want to go is keeping using of the modulestore within certain specific contexts where we can make guarantees about its performance impact. In other places, we want to stick to read-optimized versions of the data.