2024-09-19 Meeting notes

All public Working Group meetings follow the

 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?

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:

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: Let's say it wasn't in the primary list of things that got updated because we focused on the mfe. So we believe that that's important and nobody's really maintaining that xqi toolkit. When the six months time, after all of the Mfe's have dropped support. It is fair game to update at Xui Toolkit whenever it doesn't matter.

Brian Smith: And just goes completely drop 18, go straight to 20, no dual support, open a new ticket to have a window there.

Feanil Patel: Yeah, correct.

Brian Smith: We've decided that it is now behind where we want everything to be, but since maintainers haven't gotten it to where we want everything to be, we don't want to slow down, anybody making that change. Okay, cool.

Feanil Patel: Exactly. Yeah.

Feanil Patel: I think the hard part here is deciding what that list and what that cut line is of what's above, and what's below

Feanil Patel: But yeah, I think that would like Brian. You've got the gist of it, which is like, we don't want to wait for everything to be done, but we also don't want to sort of do the paperwork of a ticket per mfe. When they're all gonna land within a month of each other anyway.

Brian Smith: I guess for the long enough window on the initial dapper ticket, the discussion around, what makes the list. We can just be proactive about making sure we loop in all the right people for that.

Feanil Patel: Yeah. Yeah, I think that's a discussion that happens at the beginning and people participate. At that point in the Deborah which the depere gets announced. So that's Here's my proposed list. If you disagree and believe somebody something should be on this list. Please come talk to us. Surprise, you're probably gonna have to help. It's not going to magically get upgraded by itself. This is what we believe we have capacity to upgrade.

Feanil Patel: So you would have a drop node 18, support depot which would have a list of repos that are part of these repos have Dropped support, or have added support from the new version. We will drop support for the old version 6, months after that. And so you would have an initial announcement and then probably another announcement when the work is complete and the clock starts sticking.

Kyle McCormick: Sounds good to me and I like the idea of proposing it all with the initial dipper communication.

Kyle McCormick: here's the plan. Are we in agreement at the plan? And then the plan happens. And then, once the Readathon stuff is done. The clock starts taking for removal.

Feanil Patel: Everything. Yeah.

Kyle McCormick: That generally sound good makes sense to folks who aren't that accent.

Jeremy Ristau: I mean, to me it sounds like what we talked about last time, but again, Robert wasn't here last time, Robert's not here today so I'm not keen to say yes, let's do that for two you without getting hit involved.

Feanil Patel: I think what would be helpful is if people could hop into the wiki and help me produce the process that we just talked about as written documentation. So you can comment on there and we don't feel like wait for him to be able to make a meeting. so maybe if people could hop in to the pinned wiki page, I'm writing in there. But if you want to suggest add steps,

Feanil Patel: So I guess here's a question which is what happens? Let's say we finish all of the listed stuff. Six months. Timer starts for dropping note 18. Two months later. Somebody comes and wants to manic, maintain a package, that wasn't in the initial list. My gut says that that person now only has to support both versions for four months instead of six months. But they do have to support both versions because they're still within that six month window. Is that? Sound right.

00:25:00

Brian Smith: That sounds good to me. It means that we're basically setting a platform wide date. With that six month window.

Feanil Patel: Yeah.

Feanil Patel: Right.

Brian Smith: And they still need to respect that platform-wide date.

Feanil Patel: I think that captures everything we've said,

Feanil Patel: And we're at just about time. Does anybody have anything else to add there?

Jeremy Ristau: Yeah, I had a topic that I was hoping to talk through, but it got pushed down in the agenda.

Jeremy Ristau: Yeah. Essentially,…

Feanil Patel: The bomb team repo access. Yeah. so,

Jeremy Ristau: we're going through this.

Jeremy Ristau: No more legacy pull all having to go through core contributor for repo access but we have the RV bomb team specifically that needs to be able to take action for upgrades on many repos and they're running into. Issues where new hires can't do that. Or even one team member is taking an extended leave so they've got someone else from arbisoft taking his place temporarily and that person can't merge anything. So

Jeremy Ristau: One, I'm presenting the problem. I don't think this is To you scoped, problem. This is a team dedicated to maintaining many repose problem.

Feanil Patel: Right.

Feanil Patel: Yeah.

Jeremy Ristau: And I'm wondering if there is a recommendation for a solution here, or if we somehow need to have them become core contributors on 50 repos or something like that. Feels Difficult.

Feanil Patel: Yeah.

Brian Smith: I guess, my first question is, what are they trying to do where having direct-ride access to all of those repos is necessary. I know there are definitely going to be some things but just kind of getting a list of these are the concrete blockers from not having direct right access might be helpful here.

Jeremy Ristau: Like Landing Python de Upgrade PRS. Right. They drive that for many teams. Across to you as well as for open EDX repos. So they're having to fork and put up a PR and wait for someone to approve it. Even though the test pass and the owner might have given them permission to merge, But they don't have verbal permission to say Yes, it's fine. You can handle this for us, but they don't actually have right access to be able to merge anything. if the stance is that's life figure figure out how to make it work with the owners okay, it will be slower.

Adolfo Brandes: there's a middle ground that I don't know if you want to support going forward, but this might be a use case which is the front end all Style of theme. Which they still need to be core contributors. But to a group of repositories, instead of individually to each, I'm just throwing out there. I'm not saying it's the best solution for either side of the debate,…

00:30:00

Feanil Patel: Yeah.

Adolfo Brandes: but It could be one way to go about it.

Feanil Patel: And I mean, I think The action improvements team is actually in a similar boat where they're solving, they're helping sort of actually maintain a bunch of repositories and initially, they were not maintainers on everything because this problem is kind of complicated.

Feanil Patel: This is me shooting off the cup. So this is not like an endorsement of a particular plan, but I wonder if we need something like a Community-wide Maintainer group. Where people can pool into that resources. So the Arby bomb team and the X improvements team. Might both sort of be in this group logically of resources that are here to help us maintain across our 200x repos. And therefore they would get both access to everything but also a limited scope, which would be not enforce technically, but enforced in terms of their job description of what they're expected to be able to do here. So it's like you are given right access to all of the repos via, the CC program to be able to do maintenance work, specific to upgrades that are directed by the Maintenance Working Group.

Feanil Patel: And so anything that falls in the purview and is underneath that umbrella, they are allowed to maintain and merge. And if they are doing things outside of that, that's violation of their sort of what they're meant to do. I'm trying to think of ways in which, we give access, but, alleviate the concern that now there's people who can merge whatever they want willy-nilly across, The thing which I'm not actually worried about because, a lot of people have access to a lot of things. And that doesn't happen for the most part. Occasionally, it does happen. but,

Feanil Patel: That's one thought.

Kyle McCormick: Does everybody on the team need to have access to every repo or if there were a couple more senior members of the team with merge access? Would that be sufficient?

Jeremy Ristau: I mean I think that gets back to someone's on leave, it's the lead of the team who's on leave and they bring in Does that new lead have to become a core contributor before they can fill that position. this is an arbisoft decision, right? They said We want to make sure you have the same level of support from our arborsoft team that you normally do. We're gonna just, put in a replacement lead for a while. you…

Feanil Patel: Right.

Jeremy Ristau: that Totally. Is a fast turnaround much faster than you would expect for core contributorship or something like that. There's a new hire on the team and the new hire is on call and can't handle the on call activities without working through someone else. And that someone else in this proposal would be on leave and, it gets a lot trickier. When you say a single person on the team is the bottleneck.

Jeremy Ristau: that's the main trouble with that.

Feanil Patel: Right.

Brian Smith: yeah, I would want to find a middle ground between a bus factor of one and a bus factor of Everybody on the team is on the bus,…

Feanil Patel: And yeah.

Brian Smith: I feel like there might be a middle ground there, but I'm not sure.

Feanil Patel: All Yeah and I don't think we're gonna come up with an answer especially with being four minutes over but this is a good question for us to think about and I'm going to add a

Feanil Patel: Next time for,

Jeremy Ristau: Is this something I can log in action engineering ticket for so that I can make sure the conversation keeps happening? And instead of waiting 30 minutes or 12 minutes every week, that's a slow turnaround. When I have someone…

Feanil Patel: Yeah.

Jeremy Ristau: who talked right now and someone else who wants to go on leave and

Feanil Patel: Yeah, I think definitely start that conversation. feel free to create that ticket and that will cause the internal conversation, it asks him to happen. I think it's a accent plus community issue, so we'll definitely want to discuss with other people in the community as well, but if you want to, I don't think it's I think it's a great idea to log that ticket, and then we won't lose it.

Jeremy Ristau: I'll log it as a problem and not as a solution. Okay. Thanks.

Feanil Patel: Right. Yeah, please help.

00:35:00

Feanil Patel: And then we'll check back in next time so that we don't lose it. There's that Threadfully here.

Jeremy Ristau: It is your absolutely correct that. it's an ax improvements problem. It's an art form problem.

Feanil Patel: Yeah. Right.

Jeremy Ristau: It's a

Feanil Patel: And I bet there are people in other orgs that want to be able to help do that. baseline maintenance that can't right now. I bet there are other people…

Jeremy Ristau: yeah.

Feanil Patel: who want to do that.

Feanil Patel: I know anytime I touch a repo and I'm like, this is wrong. Let me just fix your make file real quick. And I'm not the only one with that particular compulsion.

Feanil Patel: Brian, I know we're over but Do you have a thing In particular? You want to chat through the node, 20 stuff since that's urgent for the release.

Brian Smith: Yeah, if we look at that, the github link there basically the first PR, which is just adding node. 20 to the CI matrix on front end at app payment, can't land because the CI And I verified that the CI is failing, even with just a readme change pr. So, it looks like this is something where a crime job would have helped but front end app payment, all prs are failing right now. And so my question was, Do I need to go in and make a fixed cipr for 18 specifically, then add, no 20 to the matrix then. Do the thing or can I just kind of have them combined in 881 where I've updated to 20 regenerated the package lock fix the packages that were causing CI failures and now

Feanil Patel: I think

Brian Smith: In a good place where both the 18 and 20 tests are passing.

Feanil Patel: Okay, I think I've got the fix for you.

Brian Smith: And so I'd like to just land, step two, and Skip, step one here.

Feanil Patel: I've got the fix for you which is the reason that they're failing is because you prs are from a fork. And the CI for this is currently written in a way where it does not do that correctly. If you make the same, pull requests as branches on that repo which

Brian Smith: Then why is 1 not failing? 879 is failing.

Feanil Patel: Let me see.

Brian Smith: 880 is failing 881 is not failing.

Feanil Patel: interesting. Okay.

Brian Smith: Yeah, I don't think it's a fork problem.

Brian Smith: I think it's a allowed list of a secure CVS problem.

Feanil Patel: Some sort of.

Feanil Patel: Yeah, I see that. It's like, whatever the Okay.

Brian Smith: And so, I've updated versions of things to make sure that we don't have anything that's not on the Allow list.

Feanil Patel: Allow that. God, I got it.

Brian Smith: And I did that as part of the update to 20 because I'm gonna have to regenerate the package lock.

Feanil Patel: Yeah. Yeah.

Brian Smith: I figured I'd do it once instead of twice.

Feanil Patel: Right.

Feanil Patel: Given that this doesn't have a maintenance on the deprecation list, I'm pretty. Okay with it. Moving to 20. Do other people have concerns with that?

Brian Smith: And to be clear, this is still supporting both like 18 and…

Feanil Patel: Okay.

Brian Smith: 20 tests are passing here. We're just skipping that first step of just adding 18 to the CI matrix. Yeah.

Feanil Patel: I got it. Okay. Yeah I think that's fine. That's super fine then. Yeah.

Brian Smith: Okay, cool. I wanted to get somebody. I just needed to know…

Feanil Patel: Yeah.

Brian Smith: who needs to give me the thumbs up on this one. And the answer is,…

Feanil Patel: I'm doing right now. Yeah.

Brian Smith: it's probably then cool.

Feanil Patel: I approve this message. All right. Cool.

Brian Smith: Awesome. Thank you.

Feanil Patel: 20 Minutes for X platform things, feel free to stick around Brian, but feel free to drop. If you don't want to talk about that next platform. All right. Yeah.

Brian Smith: I'm gonna head out. Thanks.

Feanil Patel: Okay. What's up, gang?

Feanil Patel: We have EDX platform things we want to talk about.

Kyle McCormick: I don't have anything.

Feanil Patel: Okay.

Jeremy Ristau: Same.

Feanil Patel: Yeah, I think right now. We're in good shape. I did want to mention that Django. Upgrade. Because EDX platform in particular because of how old it is doing the old way of doing of a declaring indexes. So it's definitely going to be a problem there. And so, I wanted to raise that as we're going to need to coordinate with people to make sure t know, I don't have the solution in hand yet, but I've seen a couple of different implementations, some of, which might require some operational, either taking migrations, or running some renames, for indexes to sort of, get them into the right shape.

00:40:00

Feanil Patel: The upshot is that by default the thing that Django does with my sequel. if you just Leave it alone. It'll generate a new migration which renames the indexes, but the way that it does it in my SQL, causes it to delete the index and create a new index which is The worst.

Feanil Patel: So there are other things in the Django upgrade That one is definitely gonna cause issues. I haven't gotten a chance to review the full list yet, but we'll definitely want to coordinate that with at least to you. And probably also give MIT some forewarning as our two sort of known master to players.

Kyle McCormick: That's a pretty crazy default behavior.

Feanil Patel: Yeah, there was a reason for it that I remember reading there in the Bug report, but I don't remember what that reason is off the top. I had it, but it did surprise me.

Feanil Patel: I think it's something to do with how the ORM is implemented, causing that change to be output it as a delete and create rather than as a move perhaps like an older version of my sequel, didn't move as an operation. Whereas Postgres has supported move of renaming indexes for ever.

Jeremy Ristau: Ask us so bad. That's gonna suck so bad.

Feanil Patel: What's that? Yeah. Yeah, I've seen some solutions that I let I need to try out to see if There are ways to tell it to do the rename by manually modifying the migrations. But yeah, this is not a thing that we can automate or junior engineers, It'll be fine. You write this migration and it's gonna be a thing where we're gonna need people to Verify these. And make sure that they get tested properly. Jeremy, I'd love your help to be able to test since you guys have, a nice giant database that you can make a copy of and then test the migrations on

Feanil Patel: But I know that's up stuff and I know that's not your domain, but I would love to be able to get your support to get them to test it so that the doesn't go down when we miss a particular migration or something.

Jeremy Ristau: Yeah, I mean, I can say that everyone who is involved in the MySQL upgrade doesn't work here anymore.

Feanil Patel: Yeah, no,…

Feanil Patel: I'm fully aware.

Jeremy Ristau: So I can reach out…

Jeremy Ristau: but there's two EDX sres.

Feanil Patel: Yeah. even just giving them a warning that this is coming in the next 12 months would be useful

Jeremy Ristau: Yeah. Yeah, I'll definitely do that. we had to get A consultant database company to help us do the MySQL upgrade. This is a nightmare…

Feanil Patel: Okay. Yeah.

Jeremy Ristau: if we really have to go and reindex our tables that took months to figure out how to reindex last time. Yeah.

Feanil Patel: I don't I need to do a little bit more research before I can say definitively that you won't have to do that. But there seems to be enough documentation suggesting that if we met we can manually update, the migration to change it from a move to a rename and that will do the right thing. But again, I haven't had time to test that so There's risk with that answer, but yeah, I'm hoping you guys don't have to do that again. But I wanted to tell you as a far ahead as I could because, If you have a large database there's a chance right now that you might have to deal with a major upgrade that either involves downtime or involves doing some fancy, my sequel shenanigans.

Jeremy Ristau: Yeah, I definitely made a note to tell the SRE team. But I will do my best to not be involved in this.

Feanil Patel: Cool, thank you.

Feanil Patel: Yeah, got it.

Jeremy Ristau: Okay, just I'm happy. The

00:45:00

Feanil Patel: The past messages. Yeah.

Jeremy Ristau: But as much as I can stay away from this, I will definitely do that.

Feanil Patel: Yeah, that makes sense. Yeah. I'm gonna spend a little bit more time on Planning that upgrade. I would love help. I don't know if there are resources, Jeremy that that would be useful to help me plan these upgrades because I know RB bomb has done a bunch of these. So I'd love if they're people that I can talk to you to help take it out the work and I know there was previous historic tooling to you for generating warning reports and converting them and building a reports out. So if there's somebody over there that knows any of that history and can help me build out this because this is essentially building out the backlog of warning squashing and if we can build out the backlog and have 12 months, I feel like we could really use it as a way to Expand the community and also seek support from people who have less expertise to do a lot of the simpler.

Feanil Patel: Warning, Cleanup across our systems. I know there's the Django upgrade.

Jeremy Ristau: If…

Feanil Patel: Project which does a bunch of code mods and part of it might be just running those across everything and doing reviews and trying it out.

Jeremy Ristau: can you start a thread about this and the Ask to You channel? And then I…

Feanil Patel: Yeah, I can do that.

Jeremy Ristau: I can rope in semester people and then I don't have to play middle man.

Feanil Patel: Got it. Yeah, that's good. this wasn't the part of the conversation. This was more they Django upgrade RB bomb part of it. I would love some help from Argo on to help coordinate the upgrade, right? I don't want to coordinate every maintenance and upgrade moving forward and I would love some help to do that. And I think don't have the capacity to do that helping but I am wondering if you can allocate coordination capacity from Rpbum because they have been coordinating some historic upgrades

Jeremy Ristau: Yeah, I mean I can say that I'm Diana is shifting into being a lead for that team as well like a two you employee lead so I can also bring her in I don't have much more domain knowledge than Brian Diana and…

Feanil Patel: that sounds great.

Feanil Patel: I'm not.

Jeremy Ristau: so Yeah.

Feanil Patel: No, that Bringing Diana in and being like, Diana can help You coordinate. This upgrade sounds great. That is helpful. I'm trying to distribute the effort of doing future upgrades.

Jeremy Ristau: Totally. Make a note of that real quick.

Feanil Patel: but, Especially with the commerce stack dropping. The number of sort of major services that need updates is shrinking nicely.

Feanil Patel: So I think there will be sort of fewer Moving forward, it'll be a lot of library updates. So

Jeremy Ristau: Yeah.

Feanil Patel: But other than that, I don't have anything else so you guys don't have anything we can in the meeting early.

Jeremy Ristau: All Just from a action items perspective. I will talk Diana about helping coordinate, the Django upgrade and then if presuming that goes smoothly future upgrades as well. and if you can start a thread in, ask to you about the database indexing part, I'll rope in SRE so that you can run with that conversation.

Jeremy Ristau: and I dropped the link in the chat here, I filed a ticket to get a solution proposal for the arabon access.

Feanil Patel: Yeah, that's it. Dropping as

Jeremy Ristau: And we have drafted a this is nothing to do with that X platform. So, sorry, I'm gonna have Hi one,…

Feanil Patel: All that.

Jeremy Ristau: the meal. Yeah.

Feanil Patel: Let me stop recording and transcripts and then we can be out of this meeting.

Meeting ended after 00:49:24 👋

This editable transcript was computer generated and might contain errors. People can also change the text after it was created.