DEPR Meeting Notes (2024)
Next
Discuss DEPR pilot addendums in the linked issue comment: https://github.com/openedx/open-edx-proposals/issues/595#issuecomment-2375740191.
smaller DEPRs will continue to happen more quickly if we need to
some operators use the previous release and stick with that until the next release comes out.
Discuss how to close https://github.com/openedx/public-engineering/issues/189#issuecomment-2310391093 (see linked comments).
This has been deployed to most of the repos without complaint
The remaining issue is only related to communicating with ecommerce, which is about to be deprecated anyway.
This will be removed with ecommerce cleanup out of edx-platform
DEPR ticket has now been closed
ecommerce deprecation is happening imminently
This will be happening before the Sumac cut.
Within the next couple of weeks or so.
2U will need to be prepared for it on their end.
Both the ecommerce repo and all associated MFEs.
learner dashboard may have a feature (or features) that are not handled in the MFE.
unclear which ones they are
and once we figure out which ones they are, if we need them
related to the MFE Rewrite work
This does not seem to be relevant to 2U, who is on the new dashboard
This panel may or may not be the only thing that’s missing: https://github.com/openedx/frontend-app-learner-dashboard/issues/336
the search functionality seems to be the main thing we’re concerned about
this should be mentioned in the learner dashboard announcement, when the DEPR gets announced: https://github.com/openedx/edx-platform/issues/35326
concerns about parity in new replacements
how can we ensure that the replacement isn’t going to drop features without notifying the rest of the community that they will be missing?
this seems to be mainly concerns with MFE development right now, but it will also continue to be relevant to things like libraries
course authoring MFE will probably be coming down the pipe
This will be brought up during the release planning meeting for Sumac.
Review the page MFE Rewrite Tracker and ensure that all the information is as up to date as possible.
@Robert Raposa clean list of accessed legacy frontend views from edx.org / Datadog and use it to supplement the above page.https://docs.google.com/spreadsheets/d/1X81NJB20hcBHcfsswenP5FhECe1w1LzXWrBlga4RmX4/edit?gid=0#gid=0 - spreadsheet was created@Kyle McCormick file a bug for view live on custom-pages studio view[inform] Attempt to complete https://github.com/openedx/edx-drf-extensions/issues/371 did not go as planned.
There is an updated plan, that may sit for a very long time.
DEPR of a CORS Allowed header ain’t easy.
Devstack deprecation coming up
What are the planned timelines?
devstack.py will probably be going away in the next couple of months
2U is working on pulling out the devstack images from the repos. currently our new process is being tested.
DEPR coming up (unclear about timeline):
removal of the FEATURES dictionary from the settings
turn these flags into standard django settings
this is almost definitely going to happen, but we aren’t sure when or the specific details of how.
22 August 2024
new DEPR tickets
a wave of new tickets have been filed
coming out of discussions about maintenance and what we (the community) would like to continue to maintain
ecommerce repos are really, really going to deprecated this time?
depr tickets getting announced to the depr channel
is this too noisy?
decided this isn’t for now. will re-evaluate as more depr work comes in
keep track of action items at the top of the page
want to make sure we ensure these things get done
how do we handle legacy frontends in edx-platform?
ticket for conversion of: https://github.com/openedx/edx-platform/issues/31620
try to enforce bugfix only in edx-platform for legacy frontends
can require codeowners approval for any changes to legacy frontend code
allow for an appeals process for exceptions
do we have a good catalog of the legacy frontends/views left?
can we make a list of where the old views should go in MFEs?
updates to MFE Rewrite Tracker
can add list of views to this page for further discussion
can we allow people to copy/paste old code from edx-platform?
‘crappy’ MFEs
need to be able to make decent, reusable APIs in edx-platform, though
prevent APIs from becoming tightly wedded to the frontend as much as possible
are their performance implications?
do we have the capacity to handle these sorts of requests to update/change the legacy frontends?
current focus is to remove old frontends with replacements
this is easier than doing the full conversion
other replatforming work?
we got updates to learner dashboard and studio frontend.
big thing is instructor dashboard
APIs underlying it is being rewritten to be DRF APIs
can we be able to do the conversion tab by tab?
create a shell for new tabs to be added to?
we already have the gradebook mfe. can we turn this into the instructor dashboard mfe?
8 August 2024
Legacy Text Editors - What would it take to move off of them?
Two Categories of Issues
Perf Issues, the new editor takes a long time to load large amounts of text.
UX Issues
How do we have the UX conversation about the editor?
2U had a practice to add a “Feedback” button into interfaces to easily give feedback changes on UX changes.
The feedback buttons went out with openedx but where does that feedback go?
In Redwood.2 it will be removed instead of going to 2U
It’s unclear what the plan was with the studio MFE and the editor, what are our options for solutions?
This should go in as a new enhancement request to the Product WG so that we can plan and discuss this as a community.
FYI, Course Authoring MFE will have a full replacement for studio
The course outline is replaced in Redwood
In Sumac the Unit editor will also be replaced with an MFE Page
This new page will not work with the legacy editor so it implicitly drops the old editor support in the new UI.
In Sumac you can still drop back to the old UI/editor but in Teak, this might not work.
What’s the plan for the problem editor? The new MFE has a lot more issues than the old problem editor MFE.
Similar, to the text editor, the MFE is on by default in Redwood but the old one will still be available.
Review of MFE Rewrite Tracker to fill in DEPR ticket section.
Note: @Feanil Patel @Robert Raposa are also discussing this in Maintenance WG.
25 July 2024
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
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
Where is that ticket? https://github.com/openedx/open-edx-proposals/issues/595
Also, Jeremy and I created https://github.com/openedx/public-engineering/issues/269
11 June 2024
Profile and Account MFEs deployed to edge
We can finally remove the old code/unblocks this ticket: https://github.com/openedx/public-engineering/issues/71
old PR (had to get reverted): https://github.com/openedx/edx-platform/pull/31893
revert PR with some additional context: https://github.com/openedx/edx-platform/pull/33542
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: [Proposal] Add Extensibility Mechanisms to IDV to Enable Integration of New IDV Vendor Persona
Node 18 deprecation
problem-builder deprecation: https://github.com/openedx/public-engineering/issues/268
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: https://openedx.slack.com/archives/C03R320AFJP/p1718116345624739
@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
visit the working group calendar for the new invite
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?
https://github.com/openedx/public-engineering/issues/263
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
[Archive] MFE Rewrite Statusarchived - 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 announcedhttps://discuss.openedx.org/t/deprecation-removal-paver/12894
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.
https://github.com/openedx/edx-platform/issues/31895 - 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 https://github.com/openedx/edx-platform/pull/34554
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: https://github.com/openedx/open-edx-proposals/pull/576
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: https://github.com/openedx/edx-platform/pull/34063
AXIM ticket for the work: https://github.com/openedx/axim-engineering/issues/881
[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 https://github.com/openedx/devstack/issues/907 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 https://github.com/openedx/edx-drf-extensions/releases/tag/v10.0.0 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.[