2024-09-19 Meeting notes

All public Working Group meetings follow the Recording Policy for Open edX Meetings

 Date

Sep 19, 2024

 Participants

  • @Feanil Patel

Previous TODOs

 Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

Python 3.12 vs 3.13

 

  • Python API doesn’t have a lot of significant changes.

  • C API has a lot of changes

  • 30% of packages currently support 3.13 explicitly

  • 3.11 is supported until 2027

  • Right now we have a mix of 3.11 and 3.12, it would be good to get to 3.12 for everything then take a break.

  • What would we do instead of Python upgrades?

    • Node Upgrade

      • Let our dependencies dictate what version we jump to.

      • This becomes simpler as frontend-base become more standard.

  • Proposal: Finish the 3.12 upgrade, skip 3.13

    • Focus on

      • Django and Node updates

      • setup.py replacement

Appropriate length of DEPR window

 

  • …Continuing discussion from last time…

    • DEPR Process Vision

      • Propose which things get the new version and old version at the same time.

      • Once we have completed the addition of the new version. We announce that the timer has started for dropping support.

      • Any work done before the date of support drop, still has to support both versions.

      • Once the drop date has been reached, any repos that still only run the old version can be updated without needing to support both versions for a given release.

  • New question that arose since last week: we have toggle dates in the code. Can we use those, particularly when the replacement is at full parity?Re: MFE Rewrite Tracker | Comment

BOM team Repo access

@Jeremy Ristau

  • Arbi-BOM team needs to be able take action on many repos to be able to do maintenance and can’t currently new employees can’t merge things.

  • What are they doing that needs direct write access to all the repos?

    • Landing Upgrade PRs across many teams.

      • Python update PRs

      • Node update PRs

    • There is a middle ground of something like the frontend-all style team.

      • Can we do something like that for other groups?

    • Can we have a core-maintainers team that any org can put resources into that would be able to merge?

    • Can we have some people with merge writes?

      • There is also an on-call rotation which is tricky.

Check on cookie-policy-banner enzyme replacement

@Glib Glugovskiy

Released in v2.6.0, can be closed

frontend-app-payment Node 20

@Brian Smith

edx-platform discussions below Here

Django Upgrade

 

  • The index changes are gonna impact us in edx-platform the most probably.

 

 

 

 Action items

Next time: Discuss access for teams that maintain many repos across the org.
@Jeremy Ristau Talk to Diana about helping coordinate the django upgrade.
@Feanil Patel Drop in #ask-2u about the potential index changes with the next Django update so Ristau can connect us with SRE

Recording and Transcripts

Recording: https://drive.google.com/file/d/1eYo0ZSt0D7C8ovKIIBMfljQvK9jxIb20/view?usp=sharing

Maintenance Working Group Meeting – 2024/09/19 09:00 EDT – Transcript

Attendees

Adolfo Brandes, Brian Smith, Feanil Patel, Glib Glugovskiy, Jeremy Ristau, Kyle McCormick, Maksim Sokolskiy, Michelle Philbrick, Sarina Canelake

Transcript

Feanil Patel: Again.

Feanil Patel: I'm in the office.

Kyle McCormick: Is that a virtual background? Yeah, I think that one booth.

Feanil Patel: Mm-hmm

Feanil Patel: It's funny how context-specific my memory is because I was like, Okay what is am I doing in Which windows do I usually open?

Feanil Patel: Until?

Adolfo Brandes: Is this an accent meeting now? Yeah.

Feanil Patel: So far. But it's public actually.

Adolfo Brandes: next meeting

Feanil Patel: the trans on time over here at accent, everybody's

Adolfo Brandes: Yeah. Letting the pace.

Feanil Patel: Yeah, exactly. The notes are here and still putting them together, but feel free to add anything to the agendas that you guys want to talk about.

Feanil Patel: There we go.

Feanil Patel: We're joking that for a second. It might be in all accent maintenance meeting. But then Jeremy and Max you guys showed up, thank goodness.

Jeremy Ristau: We can still have all the action items go to you if you want.

Feanil Patel: Would that be different?

Kyle McCormick: That's really kind of you, Jeremy.

Jeremy Ristau: I mean I have that one action night, it's good.

Feanil Patel: That's true. That's true.

Jeremy Ristau: Good anymore.

Feanil Patel: That's saying the notes are here. Wait, you can pin them now. Let me do that.

Adolfo Brandes: But neat.

Feanil Patel: yeah, so they stick around if new people join Yeah,…

Adolfo Brandes: Finally, the way to do that.

Feanil Patel: it's that time.

Jeremy Ristau: I noticed they added a pop-up window,…

Feanil Patel: Yeah.

Jeremy Ristau: too, and you lose focus on the tab, it does the little zoom box thing now.

Feanil Patel: that's fancy.

Jeremy Ristau: It is fancy. I'm not sure that I like it yet, but definitely fancy.

Feanil Patel: Right.

Adolfo Brandes: I don't like to zoom implementation much, but I'll see if this one's better.

Jeremy Ristau: Yeah. Yeah, I really get confused with what screen is being shared and everything. At least this.

Adolfo Brandes: I mean, exactly.

Jeremy Ristau: It keeps your preview and everything and Zoom. No.

Feanil Patel: And I see. Somebody made note a meeting. But they didn't update the date previously. Hold on. we've got to Hold up.

Feanil Patel: People want to sound off their previous to update them. While I do some paperwork here, that would be great. You guys don't have to Or you think banter community?

Adolfo Brandes: Let's see, I don't think I have anything there.

Kyle McCormick: I can sleep the Python 312 versus 13.

Feanil Patel: Yeah, do it.

Kyle McCormick: So Python 313 has a really aim change log on the Python API, which is cool. The C API has a bunch of changes that I don't really have a read on whether they're aim or not. So implication to see API changes, being complicated, would be back and just take longer to update.

00:05:00

Kyle McCormick: Looking at what packages support Python, 313. The list is pretty small right now. It's something like 30% of commonly as packages, support it. requests doesn't even support 313 explicitly yet. All that said, pythons on a yearly release cadence now. So I think it's kind of up to us. if we wait theoretically in one year the adoption of 313 should equal today's adoption of three 12 that makes sense. so, we could go to 312 now and then Maybe update every couple years or we could wait.

Kyle McCormick: Three thirteen as the next release. In any event free 11 is good until 2027. So Here isn't much of a rush more.

Feanil Patel: Right.

Kyle McCormick: So just a Strategic decision on our part of how quickly we want to track, Python's, latest versions and how often we want to do these upgrades.

Feanil Patel: Yeah, that makes sense right now we're kind of in a mixed state where some of our stuff is 12 and some of our stuff is 11. My thought is that, I'd love to get everything to 12, but then maybe we could do it every fourth release dual Python upgrade

Feanil Patel: So that would be every couple of years instead of every year. And we wouldn't have as much of a rush on things.

Kyle McCormick: Personally, that sounds great to me.

Feanil Patel: but other people think about, Any objections.

Feanil Patel: and 3.12 has this Weird thing that we should resolve sooner than later where a set of tools is no longer installed by default, which is impacting a lot of our packaging setup as it is today. I think moving to that kind of puts us in a better position to the future upgrades after that, I think will be a little smoother because that's one of the big breaking changes that's happening right now.

Feanil Patel: I think what's going to end up happening, is that between now and the next Python upgrade, there's actually a lot of Python packaging, infrastructure changes that were behind on that we may want to. Sort of focus on over the next couple of releases. In particular, for example, a set of that pie is being deprecated and I won't be surprised if in the next release or two of the packaging stuff, it's fully deprecated and removed.

Feanil Patel: PI Project.tamil is the new settings file that you're meant to use for everything and it's starting to have pretty good parity and I'm starting to see more projects over to it. So that's something that we'll need to figure out a migration path forward for the good news is that I think simplifies our maintenance work in the future because then, Maintenance updates for a lot of Python related. Things are in a config file rather than in Python code and their standard ways of exporting. A lot of the stuff,

Jeremy Ristau: I think the question I have would be, what will we do instead? Whenever I try to understand whether or not to do something, I always try to think about what I would get in return from not doing it.

Jeremy Ristau: And so that's what I also care because the RV bomb team is involved in the Python 312 and so I would like to know what to point them to if we're not going to be doing that or…

Feanil Patel: Right. Yeah.

Jeremy Ristau: that's time back to work on to you internal things. Like I just Wonder.

Feanil Patel: Yeah, I think. Yeah, the things that we have sort of outlined for the next two releases are. There's A Django upgrade coming up which is gonna involve a lot more brain and a lot more broad as it were in terms of both deprecation warnings, we need to deal with. So lots of code changes that are small and medium size as well as a couple of big changes that are gonna have operational impact because they changed a bit of how they do defining database indexes, and we need to manage that. So that, people don't have to rebuild indexes on the student table or the Coursework Module History table.

Feanil Patel: So Django I think is going to be the focus on the Python side. And I think Node, kind of I was talking about this with Brian.

Feanil Patel: Smith earlier.

00:10:00

Feanil Patel: And it's like node has a two-year cycle. Is that right Brian?

Brian Smith: Yeah, it's something like that. But it seems like the newer releases have a slightly longer maintenance period,…

Feanil Patel: Brad.

Brian Smith: which might give us a bit more leeway. and I know in our discussion, we were talking about having our dependencies kind of determine which versions we need to jump to because, There are some times where if we were jumping a head on a note version, we could be ahead of what our dependencies support. But we also want to make sure that we jump up to a version that allows us to upgrade our dependencies to be supported versions and also have the features that we want in time. So there's kind of a balancing act there.

Feanil Patel: Yeah, and I think you would also mentioned, which I wanted to highlight this becomes simpler. As the front end consolidation with a module federation work,…

Brian Smith: Yeah, with front end base,…

Feanil Patel: all lands.

Brian Smith: we'll have one place where we can see a lot more of the dependencies instead of having everything spread out as much as it is now.

Feanil Patel: So I think the sort of the other answer is instead of doing externally driven maintenance. We would do some of this internal maintenance to get ourselves to the latest version of our core platform and drop things that we've been meaning to drop for a long time and deal with a lot of that work.

Kyle McCormick: Just to be clear, we're finials, proposal is to finish the 312 upgrade and then skip the 313 upgrade. So we're talking about work that would take the place of the 313 upgrade.

Feanil Patel: Right.

Feanil Patel: We can even like 313 we wouldn't do for another two or three releases at least, right? Or since we have till 2027 we could potentially try to jump to 14 which makes it for a tighter upgrade window but gives us sort of More space unless resources over the entire upgrade cycle. But that's like a future discussion. I think we could have but for now. finish three 12 skip 313.

Feanil Patel: Focus on Django.

Kyle McCormick: Set up by.

Feanil Patel: It's Fireplacement. Yeah. I think for some of these, we're gonna need

Feanil Patel: Biting documents some of the mechanics of this and what we actually want to move too because there's a lot of different ways of solving the setup that pie to Pipe project Tamil is, Move from A to B but what does that look like? What are common patterns? Those are things that will want to sort of have established space and documentation force that because what I'm envisioning is like we would put this out to maintainers to do in the next two releases, you've maintenance time to do that so that we're not in a rush and also they can sort of Integrated more into their other workflows. the goal is that we have fewer last-minute updates,

Feanil Patel: yeah.

Jeremy Ristau: I objection to that.

Feanil Patel: There, let's see. So we've got a next time discussion on the Decker window. Which we have down here ticket for enabling cron on master. So that we know an external changes might have broken. Some repose that are usually not getting updates. I've been done that ticketing yet but I will do that. Brian. Did you get a chance to update the Denver pilot issue?

Brian Smith: I will bring that back to the top of my to-do list.

Feanil Patel: Awesome, thank you. And then we're talking about the six months support Windows. Which I think is as the appropriate length of Debra Window conversation.

Feanil Patel: And then teak maintenance goals.

Feanil Patel: It just sort of talks about.

Feanil Patel: but,

Feanil Patel: Yeah, we can. Yeah, so unless they're objections, I'll push the teak maintenance conversation but I do think that the Django and Node work is kind of going to be the main focus there.

00:15:00

Feanil Patel: and then Kyle, you can check off the PI 312 313

Feanil Patel: and then, Glib I see here You have an update on the Cookie Policy banner enzyme replacement.

Glib Glugovskiy: Yeah. Yeah, maybe have finalizes. So basically is now all merged into Masters in new version was released. So yeah to six zero version includes RTL results and it's already

Feanil Patel: I think that was like that in the next platform or the last two things and I was just that X platform which is a different problem. So I think we can probably call the enzyme stuff landed everywhere else. I'll make sure there's an EDX platform ticket to handle it on that side. And then that'll be done. Thank you for getting to that and then,

Feanil Patel: Jeremy. The other step is Debra tickets and work planned yet. For the front end. Deletion No. All…

Jeremy Ristau: Not yet.

Feanil Patel: and Chintan is busy on some work stuff. So I might drop that to do from our list. Okay.

Feanil Patel: I'm gonna close the check Item, from glee real quick.

Feanil Patel: Thank you. But next, let's talk about depper windows.

Feanil Patel: Kyle, do you want to start us off with the new question? That Braden post and framing that.

Kyle McCormick: Yeah, we're gonna left the discussion. On incomplete last week. Is there? Any follow-up and want to talk about there. Before I jump in this new question.

Kyle McCormick: Yeah, I would really like to have Roberts opinion on the toggle stuff.

Feanil Patel: Got it. Yeah, let me I'm gonna pull up the notes from last week real quick.

Feanil Patel: so last week, I think we had ended with

Feanil Patel: We'd ended the conversation with this notion that Instead of having individual tickets and creating a lot more sort of paperwork work for us as items are deprecated or we're dropping support for something, we would essentially split the work into two. which we would have one ticket which would track any repositories that are part of the open index release whether directly or transitively and once everything that's in the release, Is done Starts the clock. And it's six months from then that we drop support. There's a separate conversation. I want to have about whether six months is appropriate but let's table that for a second and then

Feanil Patel: from that six month clock, after six months of have passed, Or, then it is sort of fair game to update anything else. That was not a part of the release. Just without further updates, that was one version of it. The other version of it is for things that have maintainers we have that group subset separated from everything else and so anything that has a maintainer we give fair warning and six months and start the clock when all the maintained things have completed an update and then for anything that is unmaintained,

Feanil Patel: Once that deadline is hit, you can make those updates without any warning in the future.

Brian Smith: So just for my own clarification here and to make sure that I'm understanding this correctly, if we use Node 20 as an example, we would have Not a upgrade front end app. Authoring to Note, 20.

Feanil Patel: right, I think we would have is

Feanil Patel: I'm gonna say Upgrade selected packages to node 20, whether that's maintained packages or packages that are part of the release but upgrade this selection of packages to Node 20. When all of that work is completed. That starts the six month, timer.

00:20:00

Feanil Patel: And so, for anything else in that list. It doesn't matter. If nobody's done the work, they like the removal of the old stuff can happen. And they don't have to have a release in between the old change in the new change, basically.

Feanil Patel: so, for example, if we had Edxui toolkit, which is a tiny corner of that X platform.

Feanil Patel: <