Versions Compared

Old Version 3

changes.mady.by.user Jeremy Bowman

Saved on

compared with

New Version Current

changes.mady.by.user Feanil Patel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Don’t maintain a long-running branch for the upgrade. Fixes should be made in small, backwards-compatible batches that can be merged to the master branch of each repository after 1-2 days of development.

  • Automate the analysis of Django deprecation warnings. Identifying and fixing all the deprecation warnings emitted by Django is a big part of the upgrade process, and doing this manually by looking at the console output from pytest takes too long. We now have code to generate an HTML report of all the deprecation warnings generated by a repository’s test suite, and have it showing on edx-platform Jenkins test runs. This will be split into a separate package for use also in other repositories, and we will adapt code from the Python 3 upgrade to automatically generate Jira tickets from it.

  • Address specific tech debt items first that accelerate the upgrade work. A repository should manage its dependencies in compliance with OEP-18, use tox in CI with all tests passing, and use pytest as the test runner with warnings enabled before we even try to support the new Django version. Thankfully, this has already been done for many of our repositories for the Python 3 upgrade.

  • Maintain a dashboard of progress towards getting each service to Django 2.2 support. A manual wiki page has already been created for edx-platform, and the first draft of an automated dashboard for any specified service is nearly complete.

  • Use automated code refactoring for routine changes that need to be made in many places. A prototype of this has been implemented for adding on_delete=CASCADE to existing ForeignKey fields, Three such refactoring scripts have been implemented already using the bowler package.

2. Identify personnel available to help on the project

Time crunches in previous upgrades led us to allocate multiple principle principal engineers to the project, even for sub-tasks that could have been done competently by more junior developers or contractors with less domain knowledge of the code base. This time we wish to not just automate more of the work, but also delegate more of the work to outside contractors and the Open edX community. We already have some off-shore contractors with prior experience working on the project, and are finalizing plans to delegate more work to experienced Django development contractorsother Open edX community members. We will attempt to limit the staff in the Cambridge office dedicated to working on this project to about 1-2 people, although certain tasks may occasionally require additional assistance from other full-time employees. Initial code review for each pull request should be performed by a contractor other than the one who made the changes, and a final review will be made by edX staff after the contractors are happy with the quality of the work. There may be more proactive review by edX staff early in the process to make sure expectations are in alignment before too much work and re-work is done.

...

4. Hire an appropriate number of outside contractors

This was touched on before, but the final number can’t be determined until the scoping work above is complete. Some of the contractor candidates have offered to perform a paid scoping phase, which may well prove worthwhile. Once we have a reasonable estimate of total project scope, we can finalize contracts for all the contractors we expect to need. The tentative intention is to have our existing off-shore contractors focus on routine changes to edX-managed code while the hired Django contracting firm(s) focus on external dependencies and code refactoring automation, but that may shift once the final project scope is determined.

5. Upgrade pinned dependencies with Django 2.2 support available

...