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:

• 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.