DEPR Meeting Notes (2024)

Owned by Diana Huang
Last updated: Jul 25, 2024
8 min read

DEPR Project board

Next

  • Open edX conference happened!

    • is there anything that came up that is particularly relevant to this group?

      • More conversations around https://github.com/openedx/open-edx-proposals/issues/595 occurred

        • There is a lot of desire to communicate more breaking changes via DEPR.

        • Many saw DEPR as one of the more mature and clear process in the open edx community.

      • Pinata was destroyed

        image-20240715-160032.png

         

        • Celebrating

          • paver cleanup and soon to be removal

          • platform assets cleanup

          • badges implementation

          • bok-choy

          • many other things

  • Automating cross-posting to Discourse/Slack

    • if a ticket moves into ‘Announced’ can we have that auto-announced to Discourse and Slack?

    • this requires development to get done

  • Maint WG proposal for DEPR process changes

  • Review of to fill in DEPR ticket section.

    • Note: @Feanil Patel @Robert Raposa are also discussing this in Maintenance WG.

11 June 2024

  • Profile and Account MFEs deployed to edge

    • We can finally remove the old code/unblocks this ticket:

    • old PR (had to get reverted):

    • revert PR with some additional context:

  • Maintenance working group proposed using the DEPR process to communicate/manage all breaking changes in Open edX.

    • Seems like a good way of leveraging the existing knowledge and infrastructure to reduce duplication.

    • What do we need to do in order to make this change?

    • Could we make it more automated to reduce friction?

      • if a ticket moves into ‘Announced’ can we have that auto-announced to Discourse and Slack?

      • this could be similar to the discourse to slack automation to some degree

27 June 2024

  • replacement/extensibility of ID verification system:

  • Node 18 deprecation

  • problem-builder deprecation:

    • this seems to be just for an already existing XBlock in the open-craft repository

    • good to see other parts of the Open edX ecosystem using the DEPR process to announce changes!

  • maintenance working group: expand and and contract for changes

    • use the DEPR process to announce breaking changes, not just deprecations

    • this would necessitate a change to the deprecation OEP to match this update to the process

    • overall, it seems good to leverage the existing process that people know about for this

    • adding metadata to track dates so we can filter/graph/etc them instead of relying on reading and parsing the ticket only

      • discussion in slack:

      • @Kyle McCormick made some suggestions for metadata changes, could formalize this into a set proposal of new fields to create and update

13 June 2024

  • testeng-ci deprecation

    • cleaning up the last few things still using it instead of repo-tools

    • mostly being used for Python upgrade

  • Studio frontend MFE DEPR ticket incoming

    • will trying to farm out work to CCs to help clean up the old views in edx-platform

  • Removed old calendar invite in favor of a new one set up by AXIM

30 May 2024

  • Less status and more work during DEPR meetings? What if we spent the meeting time doing whatever DEPRs we were working on instead of spending time reviewing status?

    • this is planned for October

    • the docker images are needed for devstack, which has now been deprecated in openedx

    • 2u tickets for handling the migration work:

  • MFE tickets for legacy frontends in edx-platform

    • need to make sure they all exist for the existing legacy frontends

    • - may be out of date, but we could use this as a basis for ticketing

2 May 2024

  • OEP PR:

    • Can we say this is ready to be merged and accepted?

    • There’s a few suggestions left, ready to go in

    • Should be merged as soon as those suggestions are integrated.

  • Paver

    • Has been announced

      • Can discuss what this means for operators and tools that are not being maintained by AXIM (devstack, configuration)

      • This will break some old functionality, but I believe we should have replacements

    • Scheduled for acceptance May 21.

    • - this has landed to some degree as a passthrough Paver. It should be possible to switch to the new method before paver deprecation lands.

      • PR to do this replacement

    • Biggest outstanding question is about javascript tests in edx-platform - how do we end up running these?

  • Codecov

    • We moved this back into Proposed because it seems like there are improvements that can be done via configuration and we don’t have a solution for JS repositories right now

18 April 2024

  • Review the OEP PR:

  • Redwood: schedule has changed. currently planned for May 9 for cut.

    • we have some deprecations that are waiting until this gets cut to be worked on/merged.

4 April 2024

  • Update the OEP to match the new process listed below

    • Hopefully the new process has been updated to accommodate everyone’s feedback

      @Deborah Kaplan to draft a proposal (create a PR) to update the OEP to match the proposed changes below

  • Go through the board, move tickets to the appropriate status according to the process

    • Moved tickets around and assigned new owners to some of them.

  • Send out announcements about the changes to the DEPR process.

    • This will happen once the PR to update the OEP has been created

  • [Diana] 2U is in the process of planning out how to handle the removal of the devstack infrastructure from openedx

21 March 2024

  • [Diana] [inform] Devstack has been deprecated/archived. 2u has created a fork.

  • [Feanil] https://github.com/openedx/public-engineering/issues/51 - Does Kyle’s latest suggestion here make sense? Should we proceed with this?

    • AXIM planning in taking this on

    • Planning on pushing deprecation work until after the Redwood release

  • Discussion: how do we handle breaking changes in, for example, edx-platform in the future?

    • tutor maintainers will handle updating Tutor, but all the other operators will need to be informed and make the appropriate changes

    • ex: moving static asset compilation out of paver

    • 2U interested in maintaining a list of incoming work from DEPR/other community work that needs to be addressed by 2U

      • Can we make this information available to the public as well?

      • We are currently maintaining it within 2U boards, but maybe we can do this going forward

      • We aren’t doing a good job of marking tickets with the last open edx release

    • Should we have new metadata

    • Can we be better ownership of DEPR tickets and the work?

      • The person owning the DEPR ticket can update the ticket with information about the scheduling of the removal.

      • Encourages a conversation with the concerned parties about the timing and blockers internal to their organization regarding the DEPR.

    • We should update the OEP to reflect the new expectations around the people who do the removal

      • The person who is planning on doing the removal should post a comment to the ticket to let the people following the ticket know that the work is starting

      • Maybe we shouldn’t allow to the tickets to move forward out of ‘Proposed’ unless there’s an owner.

        • If the owner drops off the ticket, we going to move the ticket back to ‘Proposed’

        • We want to preserve ‘Communicated’ as the commitment to actually do the thing.

      • Proposal to update the process:

        • People can post things to Proposed whenever they want.

          • Optionally an announcement can be pushed to the community whenever to inform the community that we’re thinking of doing this deprecation.

        • Whenever someone comes around who wants to push the DEPR forward, they can pick it up and commit to being owner.

          • When they pick it up, they should be able to view the history of the DEPR via comments and state changes.

        • If they have to drop it, we move the DEPR back to Proposed.

        • Owner is responsible for informing followers on the DEPR ticket when the DEPR ticket moves through the various stages because GitHub doesn’t notify followers when this happens.

        •  

07 March 2024

  • [Diana] Don’t think we managed to talk about CourseGraph before

    • Who uses it besides 2U? I can file a DEPR, but I just wanted to get a sense before I did anything here

    • MIT pushes course data into a separate data store

    • This would allow us to drop a dependency on Neo4J from edx-platform

    • We can try filing a DEPR to see what happens

  • [Diana] Overlap with Maintenance Working Group

    • How do we want to split duties/areas of focus?

    • Should we be doing things that they’re doing right now? Are there things we’re doing that they should be doing?

  • [Diana/Feanil][inform] Tubular deprecation

    • The new plan is to remove the old retirement code from the tubular repo before deprecating/archiving it.

    • 2U is in the process of moving over, but it might be worth noting for other groups who use these retirement scripts

  • [Robert] What kind of process can we put into place in order to inform the community about things that are moved into ‘Done’ so that final org-specific cleanup can happen?

    • ex: bok-choy and 2U

      • Diana to pick up this action item to do the search on the edx org

22 Feb 2024

  • [Diana] Usage of CourseGraph? Can we rip out the integration in edx-platform?

  • [Feanil?] Tubular deprecation

    • The retirement scripts have been moved into edx-platform:

    • AXIM ticket for the work:

  • [Diana] Timing of migration/deprecation of devstack and configuration

    • Have we gotten enough pushback from the community to justify leaving it in the openedx org? Is this just waiting on 2U?

    • [proposal] (Discussed in Maintenance WG)

      • Update description to describe the new plan of 2U fork and of someone else maintaining (until Tutor is ready) or it being archived. (Make it clear in the DEPR that it has materially changed via warnings and/or closing and replacing.)

        • 2U will update the description and make a new announcement

      • Send an updated announcement that notes the new plan. 2U to continue to maintain devstack during the two week DEPR review period.

  • [Diana] Configuration

    • Update README to mention it’s deprecated

      • Update the openedx.yaml so it’s not tagged for release for Redwood

08 Feb 2024

  • [Dave] Announced django-splash deprecation.

  • [Dave] Kyle announced the Blockstore DEPR

  • [Diana][inform] Configuration updates

  • [Diana] Devstack DEPR - what does this mean on a practical level?

    • Should we talk to the community about who is still using it?

      • What announcements should we make?

      • Send a message to Slack about this deprecation.

    • Did add a notice to the top of the devstack repo.

    • Might still be better for MFE development, but there is a concerted effort to improve this.

  • [Robert] Insights DEPR, and potentially a meta-DEPR question.

  • [Peter] Has anyone been able to look at the edx.org xqueue database to find other groups using xqueue and/or xqueuewatcher?

    • Adam Blackwell did some digging on this that i will need to do some followup on, though he’s not at 2U anymore.

      • Adam told me that Daniel Streby would be the contact for graders. Should I reach out to him?

        • Not right now. The 2U folks will probably try to handle this side of things.

  • [Diana] Tag MFE DEPR tickets and create a blocked

25 Jan 2024

  • [Robert] [inform] [DEPR]: USE-JWT-COOKIE header #371

    • I just released which removes this header. Just some long tail work left, including services upgrading this library.

  • [Diana] Devstack DEPR

    • 2U will take full ownership of the repo for now. We will try to keep it in the openedx org until a later date.

  • [Diana] Insights DEPR

    • 2U are the only people currently running this, as far as we know

      • will follow up internally with 2U managers about how to handle the deprecation of it for 2U’s use case

  • [Diana] MFE code in the configuration repo - can we get rid of it?

    • May want to make a DEPR ticket for this

  • [Diana] configuration DEPR

    • Suggested path forward: move to openedx-unsupported and allow individual organizations to run their own forks

    • 2U should put a comment about what we’re still using in the configuration repo

      • Mostly deployment of edx-platform and a few other non-containerized services

    • Will reach out to other long-time providers about their use cases.

  • [Feanil] 37 Repos

      • 2nd tab

      • Need to add to the

11 Jan 2024

  • [Adolfo] Axim’s picking up the frontend deprecation project (which we last discussed here in 18 May 2023) in earnest, for a December 2024 delivery. Would love a braindump from folks about this.

    • Jeremy Bowman is probably the best person to talk to about this, for high level strategy discussions about this work.

    • We need to get started on this soon

  • [Robert] [inform] Created [DEPR]: EDX_API_KEY #34039.

    • I don’t expect removal action on this, but just needed it documented to answer a question in Discuss.

    • Once accepted, a quick win might be updating a couple of docstrings, as details in this DEPR comment.

  • [Robert] [inform] The main effort behind [DEPR]: USE-JWT-COOKIE header #371 is nearly complete.

    • I may pass along the long tail work to someone itching for DEPR work.

  • [Peter] [question] Any news on deprecating xqueue and xqueue-watcher?

    • Is October still realistic for this?

      • We need to check in with the other course teams about this outside of MIT

      • What is the migration effort?

    • What is the actual cost of running this vs. running an alternative?

    • Finding courses still using it: look at the xqueue databases

  • [Diana] review board

    • Suggestion: Add a task list to our DEPR ticket template.[