THIS PAGE IS OBSOLETE

Please see https://open-edx-proposals.readthedocs.io/en/latest/processes/oep-0021-proc-deprecation.html

This proposal is being created as part of  TNL-6125 - Getting issue details... STATUS

Proposal 1 (Transfer to different repo)

Summary

A new organization, edx-deprecated, will be created. When repositories within the edx organization are no longer supported, they can be transferred to this organization to clarify the state of the repository and reduce spurious Gemansium warnings. Transferring ownership allows the preservation of Github history and provides forwarding links.

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. If the repository has a openedx.yaml file, add "obsolete: True" to that file.
3. Transfer ownership of the repository to edx-deprecated. See /wiki/spaces/IT/pages/67338403 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.
6. Remove any integrations which aren't relevant anymore.
7. Remove any webhooks which aren't relevant anymore.

Pros

• The edx organization is no longer cluttered with unsupported/obsolete repositories
• Hopefully Gemnasium would automatically stop reporting on these repositories (though this needs to be tested)
• These old repos do not need an openedx.yaml file (which could be good, as nobody wants to own them anyway)

Cons

• We have another organization (edx-deprecated) to "maintain".
• It will be difficult for people to find these repos by search (although forwarding links will work for people that already know about them).
• Moving the repository duplicates the "obsolete" flag in the openedx.yaml file-- it provides another way of marking a repository as obsolete/deprecated

Proposal 2 (Use openedx.yaml file "obsolete" flag)

Summary

Leave all repositories within the edx organization, and utilize the "obsolete" flag in openedx.yaml to indicate deprecated repositories. For now, Devops manually removes obsolete repositories form Gemnasium, but in the future automation could be added.

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. 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.
5. Remove any integrations which aren't relevant anymore.
6. Remove any webhooks which aren't relevant anymore.

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-- either IT or Devops would have needed to handle the repository transfer anyway, and the work involved to change the monitored status in Gemnasium is probably simpler.

Cons

• 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.
5. Remove any integrations which aren't relevant anymore.
6. Remove any webhooks which aren't relevant anymore.

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.

Proposal 4 (Proposal 1, with an optional hand-off)

Same as Proposal 1, but prior to obsoleting a repo, ask on edX code whether someone would like to take ownership of the repo. If so, transfer to their github org, hand over rights, and maintain a fork of that in edx-deprecated. If not, proceed as per Proposal 1. In either case, change license to Apache.

Pros

• In the unlikely case someone builds something off of it, we may have something we can use down the line. 
• We've made a greater community contribution.

Cons

• We lose some control.

I think this may be just academic for the current repos, which are very edX-specific, but it may become important with tools like EASE, djeventstream, and similar, should we choose to deprecate them as well.