Versions Compared

Key

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

This proposal is being created as part of 

Jira Legacy
serverJIRA (openedx.atlassian.net)
serverId13fd1930-5608-3aac-a5dd-21b934d3a4b4
keyTNL-6125

...

  1. Update the README.rst file in the repository to state that it is deprecated and that the repository may depend on out-of-date libraries with security issues.
  2. If the repository has a openedx.yaml file, add "obsolete:True" to that file.
  3. Transfer ownership of the repository to edx-deprecated. See How To Transfer a Github Repo From a Personal Account to edX for an idea of what these steps may look like; a dedicated How-to will be created for the process once this proposal is approved.
  4. Send an email to edx-code@googlegroups.com notifying the openedx community about the change.
  5. If transferring a repository to edx-deprecated does not automatically cause Gemnasium to stop reporting on it, create a Devops ticket for this additional piece of work.

...

  1. Update the README.rst file in the repository to state that it is deprecated and that the repository may depend on out-of-date libraries with security issues.
  2. Add "obsolete: True" to openedx.yaml (creating the file if necessary).
  3. Send an email to edx-code@googlegroups.com notifying the openedx community about the change.
  4. Create a DevOps ticket to change the status of the repo to "non-monitored" in Gemnasium.
    1. In the future, automation could be added that uses Gemansium APIs to update the monitored status based on the value of "obsolete" in openedx.yaml.

...

  • The edx organization will continue to have a mix of supported and unsupported repositories, which can be confusing.
  • It is unlikely that we will ever automate the Gemnasium process, as that would create code that would need to be maintained, and this operation is rarely done.
  • Is it necessary to define an "owner" for an obsolete repository in the openedx.yaml file? In reality, we don't want to own this repositories.


Proposal 3 (Deprecated Branch)

Summary

Move the code from the master branch to a deprecated branch. This leave the repos in place, allows us to keep the openedx.yml in the master branch, makes it very clear that the code is deprecated, and gets rid of Gemnasium warnings. (Ref: https://helloanselm.com/2013/handle-deprecated-unmaintained-repositories/)

Steps

  1. Update the README.rst file in the repository to state that it is deprecated and that the repository may depend on out-of-date libraries with security issues.
  2. Add "obsolete: True" to openedx.yaml (creating the file if necessary).
  3. Send an email to edx-code@googlegroups.com notifying the openedx community about the change.
  4. Follow similar directions as proposed here: https://helloanselm.com/2013/handle-deprecated-unmaintained-repositories/ to:
    1. Clone the master branch to a deprecated branch.
    2. Remove all code from the master branch
    3. Move a copy of the openedx.yaml with the obsolete: true flag back to the master branch.
    4. Create a short readme.md in the master branch with links to alternatives or information about why the repo was deprecated and where someone can find out more information about how to move forward.

Pros

  • We don't need to create and "maintain" a new organization.
  • We are not duplicating the "obsolete" information in openedx.yaml.
  • No extra help tickets are needed, as Gemnasium monitors only the master branch by default.

Cons

  • The edx organization will continue to have a mix of supported and unsupported repositories, which could be confusing, but you'd have to try really hard to ignore it.