Maintenance Working Group Meeting – 2024/09/12 08:55 EDT – Transcript

Attendees

Adolfo Brandes, Awais Qureshi, Brian Smith, Feanil Patel, Feanil Patel's Presentation, Jeremy Ristau, Kyle McCormick, Tim Krones

Transcript

Feanil Patel: The only.

Feanil Patel: Anyways, end up.

Adolfo Brandes: Hello.

Awais Qureshi: Hi everyone.

Adolfo Brandes: Wise.

Feanil Patel: I notes are here, if people want to add things,

Feanil Patel: I'm just going to move some things to do. So next time things into The actual agenda.

Feanil Patel: At the Geopa chance to look at the Python 313 change. Login.

Kyle McCormick: I did not.

Feanil Patel: Alright, we'll leave that on the future next times. I did put in this stepper for Ubuntu 2004 There's an announcement and a Decker. I believe the comment period is still. Monday, the 16th. So, if you have feelings about that, In a lot of places where we've moved to latest. There's been zero issues so we've just merged a bunch of those because for Pure Python, libraries that made sense. Yeah, that's platform. There's some complexity that I can go into people are curious on the EDX platform side of the world.

Feanil Patel: and we have,

Feanil Patel: I know that Glebe and I just saw a PR come up from Glebe on the just update. So I assume he's probably working on and also the Paragon update in that repos, I think he's doing a bunch of maintenance over there, so hopefully this will close out soon.

Feanil Patel: Jeremy that I'm in assume the dapper tickets are not. Up yet.

Feanil Patel: Brian and Adolfo. Is this? The

Brian Smith: Yeah, that's the dapper and I'm going through and…

Feanil Patel: Mess.

Brian Smith: I'm going to comment on my forum post about that saying that it's accepted as well. I had frozen a while back…

Feanil Patel: that's,

Brian Smith: but then forgot to mark it as accepted. But now I'm doing that.

Feanil Patel: I'm gonna check it off this list.

Feanil Patel: I think at this point it is in other processes and we don't need to check in on it. Awesome. Thank you for doing that.

Feanil Patel: first item for discussion today is deprecating items in repos that don't have maintenance.

Feanil Patel: This came up, I think, Now we're having a discussion previously and this came up, which is that there are a bunch of repos that have Node 18 support right now but no maintenance but are also not sort of like a part of the named release but our sort of components in the system and it'd be really useful to both, not do that upgrade today, but then not have to wait, six months from whenever we do the upgrade to do the cleanup. So the idea that I think we had was sort of it'd be great for things that are sort of in this unsupported realm or in this unmaintained realm, which I think we're gonna have for a little bit longer. to be able to say,

00:05:00

Feanil Patel: six months from this day, everything that is under maintenance late, that is not maintained can just drop support for old things. If anybody sees it and wants to make that change in the future because they ran into that repo, for whatever reason they can just drop the old thing and pick up the new thing without having to do, sort of or that window of maintenance, sort of is on the other putting the onus on people who depend on it to deal with it rather than on us to Have things that are not maintained, but then also have a lot of work to keep them moving forward.

Feanil Patel: And the objections.

Jeremy Ristau: Are you talking specifically about F-18 or are you talking about anything that you in the future?

Feanil Patel: Nudity is the example, but I am talking about it. more generally, We have other things that were differing right now, like the python three eight, eleven. Twelves comes to mind. there's a bunch of repos that I ran into when I was doing the Oakland two upgrade that they were still running Python 38 and it was nice to be able to just drop three eight.

Feanil Patel: But if we had followed, the other way that could have gone as I would have to add Three 12. And then wait, six months before I could remove 3/8 and that would have been sort of adding a maintenance burden that didn't feel necessary.

Jeremy Ristau: But depere's, not reposition. If we were to walk through the scenario or long term, we would have already had a Python 3/8 ever ticket. That would have had a date. If you discovered something that was missed, you could still clean it up, right?

Feanil Patel: it depends, we've sort of gone back and forth on whether there are repo specific deckers or generic deckers, because Not all repos are ready to make that lead at the same time and we don't necessarily want to hold back certain repos because other repos are not moved forward yet. So, an example of this would be Edex platform had node 20 running three months ago and so I made that pepper three months ago for EDX platform because there's plenty of time to move to Know 20 for EDX platform at that point because it's ready to go. And it's big enough that it's sort of worth doing it. Independent of all the mfe's, getting updated which we're still sort of in the process of doing

Feanil Patel: So it does happen that sometimes you get repo specific ones, and sometimes we haven't really talked about this a lot, which is why I thought it would be useful to sort of discuss further.

Jeremy Ristau: Right.

Feanil Patel: Because we're in this place where I think both can happen where we do sort of these generic steppers and specific steppers. And in my mind I've been sort of pushing more even if it's batches of specific so that each stepper is actionable. But this is a case where having that generic upper is actually more useful. So I wanted to sort of discuss before we started using either both approaches or decide on one or the other.

Brian Smith: So in a sense, This use case is an argument in favor of more generic steppers over the more specific ones. But I do find the more specific ones.

Feanil Patel: Right.

Brian Smith: Easier to understand, It's something where it's some, if being able to say all of the tutor supported Mfe's. As of sumac are going to work with both node 18 and Node 20 at which point we will be able to drop note 18 from the CI. And if things break in there, that will be okay, sometime during soon after sumac is cut,…

Feanil Patel: Right.

Brian Smith: So, But that doesn't necessarily make sense if there's a dependency in there, that didn't build that way, and yeah.

Feanil Patel: Yeah. Yeah. I mean, one of the things I kind of imagined as a workflow and people could tell me if this makes sense or has issues is we do the work for the things that are sort of in the core of the community supported releases. And at some point we just decide everything else we don't have capacity for or is not a high enough priority. And then we do the generic one at that point as a way of closing out because I think there's this tendency to have this long tail of but that one repo is left still and we should eventually get to it. but if it's not causing an issue and it's not like A priority for the community then it doesn't feel like we need to get to it right away. So having this tale of having a repo a dipper that's just like this point, anything that is on that old version is

00:10:00

Feanil Patel: Fire beware use at your own risk. We may upgrade at any moment. And drop the old support and add the new support and may it'll happen without necessarily warning.

Brian Smith: But basically a floodgates or green light Denver or…

Feanil Patel: yeah, yeah, exactly sort of like

Brian Smith: all right. You find something where we're still using something earlier than Node 20 know that at this point, somebody can just merge a note, 20 upgrade without going through whatever process, the floodgates are open for no 20 now.

Feanil Patel: Right, no 20 is now default. And anything. That isn't running. No 20 can drop support at any time.

Feanil Patel: Or it would more like Node 18 is now dropped anything that has Node 18.

Brian Smith: So yeah.

Brian Smith: Yeah.

Feanil Patel: Support can remove it whenever they feel like it

Brian Smith: If we're on node 22 by the time, somebody gets around to touching that repo and…

Feanil Patel: Right. Exactly.

Brian Smith: that jump could happen. Yeah.

Kyle McCormick: Sounds like we're to be overlapping support for maintained repositories.

Feanil Patel: Yeah, which I don't think is an unreasonable thing to do.

Feanil Patel: 

Brian Smith: Otherwise we're putting extra burden on someone that is willing to step up and maintain something that nobody else is maintaining and saying, You have to do this in an overlapping support manner as opposed to accepting the fact that somebody is bringing something that hasn't been touched in a long time into the world. So, we actually use it.

Feanil Patel: Through modern.

Feanil Patel: yeah, my son says that I think I want to sort of Reduce the barrier for entry in terms of process for new maintenance where we can. so that if they're excited to maintain something and bring it up to spec, That they're not also signing up to do a lot of paperwork as a result.

Jeremy Ristau: It's almost sounds like. Expectations for maintained versus unmaintained repos instead of expectations for Denver. if there is a general clause that's as os, follow healthy maintenance practices. the depper window you can rely on that because it is a maintained repo if it is an unmaintained repo, you cannot rely on Processes that are put in place, because there is no one to abide by those processes that is the maintainer. And if Dippers have a,…

Feanil Patel: Right.

Jeremy Ristau: Defined scope. I wouldn't see this as a scenario that pops up, So we had a 3/8 that particular and it listed all of the repos. That would have 3A from them. You either.

Feanil Patel: Right.

Jeremy Ristau: Complete the work or you don't complete the work. But you've stated what work is going to be in scope and…

Feanil Patel: Yeah.

Jeremy Ristau: then if something is out of that scope all on maintained repos, they don't get upgraded and they don't have three a deckard and they are just using your own risk because they are on maintained. It feels to kind of independent topics one around expectations for unmaintained repos and…

Feanil Patel: Okay. I like that.

Jeremy Ristau: the other around what is in scope for a dipper.

Feanil Patel: Yeah. Yeah I think that's a good point.

Brian Smith: but We did have question. I think, the reason that they're tied together is if there is an unmaintained repo and somebody comes upon it and wants to upgrade from Python 38 to 311 or 312. Do they then need to say? Hey six months from now. I am going to drop three eight support or can they just say this repo seems to be unmaintained? I want to get it into the modern world and do Let's just do the upgrade. So are we adding a six-month? Wait, period. Or Incurred or making somebody do overlapping support when they want to just be able to use something.

00:15:00

Feanil Patel: And I think that's the sort of where this goes back and forth. And I wonder if we can actually just Add a clause to I'm in front of where to document this and sort of if this is something an update to the maintenance saying, when you take on maintenance ship, anything that is considered out of date, can be updated without warning or Without needing to do sort of. A period of overlapping support and that's kind of where setting it as a dapper standard made more sense.

Feanil Patel: but, it does feel like it's sort of Straddles, both of those worlds, in a way that makes it a complex issue.

Jeremy Ristau: I definitely understand not wanting to put a six-month. Freeze on a newly maintained repo that's I think a large hurdle.

Jeremy Ristau: Is This is a interesting one.

Feanil Patel: Yeah. Yeah.

Feanil Patel: All right. I'm gonna propose that what we do is maybe as a because we have this. I like Deborah Pilot ticket that we're sort of keeping track of some of these things on, what I'm going to propose is that, as a part of that, we just make it clear that If a repository is unmaintained,

Feanil Patel: We don't consider it needing to go through. The six-month upgrade period, because we're still in the sort of Pilot phase of that six month period thing as an idea. So, I think for now it's easy enough to just go on that github issue and just say this is not relevant for repos that are not maintained.

Feanil Patel: Would.

Kyle McCormick: I would propose amendment to your proposal.

Feanil Patel: Yeah. Yeah.

Kyle McCormick: The six month window applies. But if it finishes for the unmaintained repos, whether or not support has been added, so I guess what I'm trying to say is we shouldn't make breaking changes and maintain Outside of the declared window…

Feanil Patel: Until after.

Kyle McCormick: but after it's very good.

Feanil Patel: so, it's something like,

Adolfo Brandes: just a side question. Are we planning on having many on maintenance repos? I guess.

Feanil Patel: I mean, planning is one thing, and reality is another,…

Adolfo Brandes: Yeah. Yeah,…

Feanil Patel: My plan is that everything is maintained immediately when I announced at 12 months ago,…

Adolfo Brandes: I know.

Feanil Patel: but That one or…

Adolfo Brandes: But yeah, I know. Yeah.

Feanil Patel: six months ago but that plan did not, come to fruition. Unfortunately, I think we're working towards reducing the number of unmaintained repos and people are stepping up to maintain your repos like that. these are things that are all happening, but we're gonna be, I suspect in this situation. Where there are unmaintained repos and we want to break and a maintainer comes on and we want them to sort of have the freedom to make these changes. establishing a set of rules so that they can be supported in that makes sense to me. Once all maintained repos have, Dropped support or something.

Feanil Patel: It is fair game to drop support in. And the unmaintained.

Feanil Patel: People. What do you think of That capture what you're saying, which I agree with. I just want to sort of capture The negative.

Kyle McCormick: That looks good to me.

Feanil Patel: Would you mind just like adding that to that Github issue?

Kyle McCormick: Did anyone else have comments on it?

Brian Smith: I have a minor comment on it. I'm not sure…

Feanil Patel: Get change it.

00:20:00

Brian Smith: how to change it up. I just know Let's think about note, 18 being dropped that happened on Adex platform first and then we've got the tutor supported Mfe's and we've got a couple more mfes that are still supported, but aren't the standard tutor supported Mfe's. And then we've got stuff that's just out of that scope completely. So what counts as all maintained repos in that scenario for any given repo because we're not doing a note, 18 blanket all maintained repos Dipper. We're doing Here's the Tudor supported Mfes Dipper and then here's another set of things. Yeah.

Feanil Patel: I would are good.

Kyle McCormick: Hi.

Feanil Patel: You go first.

Kyle McCormick: My inclination, is that instead of just imly. Dropping support and unmaintained repos. should in one of those steppers explicitly say this will include unmaintained repos, whether or not they are upgraded. Something along those lines. And that's the window that matters.

Feanil Patel: Yeah, I kind of yeah.

Feanil Patel: I kind of see it as if we look at them maintenance board and we've got that top level maintenance ticket. At some point, you're gonna want to close this ticket.

Brian Smith: Yeah, just adding a comment on that ticket saying when this is closed any unmaintained repos or…

Feanil Patel: Whether?

Brian Smith: on upgraded repos, are now fair game.

Feanil Patel: Yeah And you may want to make a one-off diaper for it which is immediately accepted but then essentially announces it to the channels that Denver is our because everybody started tied into the Decker channel. So may involve one last step or when you're ready to close this.

Brian Smith: Yeah, this sounded like a plan. Now, I like this.

Feanil Patel: Okay, cool. Do you want to change anything in? The wording to reflect that or Do you want to make this update to that issue? Brian. And maybe add some examples or something. So,

Brian Smith: yeah, let's add that as an action item for me.

Brian Smith: I want to make sure that I have a chance to Digest it before.

Feanil Patel: Digest that yeah.

Brian Smith: Before I start adding a bunch of words.

Feanil Patel: Kyle. Can you drop a link to that issue? I don't want to go searching for it.

Jeremy Ristau: Just sort of. Higher level question. a pepper ticket for EDX platform and then a debit ticket for tutor MFES and then a defer ticket for other MF.

Jeremy Ristau: Is there? This situation that we want to be in where we are not fully deprecating things.

Brian Smith: so, I think one of the main reasons for splitting it up is we haven't been putting dippers out until you can run both at the same time state, at least for note, 18 and 20, the idea is once we have upgraded the set of things within a decker to support, both the previous version, note 18 and the current version node 20, then we can say, Hey, we're going to drop note 18 because there is now something else that you can use and we don't want to be in a nebulous six months from

Brian Smith: When everything TM is ready to use node 20, right? We want to have a specifically six months from now. When you can use node 20, for all of these things, we are able to drop support for node 18.

Jeremy Ristau: I guess I'm just not really sure why. Everything that is discussed isn't just tasks inside of a dipper.

Jeremy Ristau: Stage One Phase, Two Action, three, why is it chopped up at the top level?

Feanil Patel: can you talk a little bit more about sort of how you envision it because I'm having trouble picturing sort of like, woodwork

Jeremy Ristau: I'm not sure either. this is more me trying to grapple the current structure. and the way that I think about work management,…

Feanil Patel: Got it.

Jeremy Ristau: I guess there is a single initiative and…

00:25:00

Feanil Patel: Did.

Jeremy Ristau: that initiative can break out into as many spidery pieces as needed. But you would not have seven initiatives for the first level of breakdown.

Feanil Patel: Yeah.

Feanil Patel: I think. My perspective on it, is that the initiative is over here on the maintenance board. And that the deprecation is a Side effect of this initiative. but from an operators perspective, I care a little bit about the initiative but I care a lot more about when my stuff is about to break and being able to just see this Delta is about to happen. And here's what you need to do to sort of get ahead of it. And sort of dipper is kind of oriented more around. that perspective then or at least that is the tactic.'re currently taking,'ve Deborah's have, historically, been we're gonna do this thing.

Feanil Patel: And that sort of biggest feedback we got from that was, like you said that four years ago, that you were gonna do that a month after you posted that. And then it was two years before you actually did it, and it became this promise that was never fulfilled. and shifting that to more concrete things where it's like, you can trust that a diaper is gonna happen is I think a really valuable Change. But as a result of that, we're getting much more specific about what a depper entails.

Jeremy Ristau: Okay, I think Kyle, you have something.

Kyle McCormick: To your specific question. Jeremy of why not a task list on an initiative.

Kyle McCormick: I think it comes down to. Us needing to get.

Kyle McCormick: I guess consent to make a breaking change. And have this deep by default six month period of overlapping support. if

Kyle McCormick: It were a top level initiative with steps. The question that comes to my mind is, would we get consent for every single one of those steps when we start the six-month period separately for all of these? Or would it be like, Once we do all the upgrades then we wait six months. And I think there's a desire on them on our side to not be stuck. Waiting six months after the very last lowest priority. At least maintenance repository is upgraded.

Jeremy Ristau: And that's my similar concern with breaking it apart. And having multiple debtors, it's like you create another dapper and that starts another six-month window, whereas, if you took the node, 20 example, In my head, I would see absolutely what I see here which is a top level. This is what we want to accomplish. We want to upgrade the platform in its entirety to node 20. That should have a corresponding contraction ticket right in the expand contract model. So you go over to Depper and you create one DECKER node, 18 ticket.

Jeremy Ristau: And that one decor ticket says, the entire platform is fair game to remove node 18, six months from two weeks from now, because we need to comment period, or whatever, six months from approval and…

Feanil Patel: Yeah.

Jeremy Ristau: and then inside that decor, ticket becomes the list of repositories that are in scope for that deprecation. And each one of those is a task in that people remove node 18 from that repo. and in this upgrade ticket is the corresponding upgrade ticket in every repo to upgrade to note 20. So you have the depart tracking all the removals and you have tracking all the upgrades and it's just two top level to get that. Everyone can refer to in regards to the timeline and the status. but I might be simplifying the problem so that's why I just wasn't understanding

Feanil Patel: All right. Brian you go. Then I'll go and then we got to end this meeting. So we can have the next meeting.

Brian Smith: Yeah, so you touched on a thing of six months from the two-week comment period ending saying, Six months from communicating, We are going to depot, which I don't think is how we've been understanding I think we've been understanding it as six months from when you can as an operator move to the new thing that is replacing the old thing that we are decorating, right?

00:30:00

Feanil Patel: Yeah.

Feanil Patel: The thing I'll add to that is that we might be arriving at this because of the change. We just made, which is that If in our maintenance ticket, we're only going to target these known maintained repos that are part of the release. We actually have a much smaller list now than everything.

Feanil Patel: At that point, it might become more feasible to have a single ticket for the entire node 18 to 20 transition. On the Denver side. I think, historically. We were struggling with this question of Where do the unmaintained versus maintained Who's going to do that? But Brian, I think the question you brought up as kind of like let us to this place where maybe it is feasible to do it this other way where it's a combination, right? It's like if you do have to wait till everything is done before, you can put the dipper in, but everything in the organization. It's everything that is a part of the open EDX release. Which is a much smaller subset of everything.

Feanil Patel: and even in that, maybe it's just everything in that that's maintained So I wonder if maybe it's becoming more feasible, not under this new perspective to do the thing. Jeremy is suggesting but it wasn't as yeah. Maybe we could I'll add a next time for continued discussion.

Brian Smith: Yeah, that sounds great. I think Marinating on this. for another little bit and…

Feanil Patel: Yeah.

Brian Smith: coming back with more flushed out ideas, it seems like a good idea.

Feanil Patel: Yeah. I would say Brian, you should do the update to that Decker pilot issue with the change because I think that change we want either way,…

Brian Smith: Hundred percent. Yeah.

Feanil Patel: but then that might have implications that we can talk through.

Brian Smith: Yeah, that'll be an example we can use when thinking about how we want to do this more overall.

Feanil Patel: Yeah.

Brian Smith: Yeah, sounds good.

Feanil Patel: cool. That'll show up for next time. Six months support windows, doesn't seem prudent is getting bumped again, Kyle.

Kyle McCormick: That's fine. It's the same discussion, really?

Feanil Patel: Yeah, I think it's not unrelated. but, it's like, We should talk about it more directly there.

Feanil Patel: And then, taking maintenance goal or bumping. All right, I think we should transition over to EDX flat form related stuff that you guys want to stick around for that, Otherwise feel free to drop.

Brian Smith: Thanks everybody.

Jeremy Ristau: Thanks.

Feanil Patel: 

Feanil Patel: I just had one topic. Does anybody else have other topics? They want to discuss.

Kyle McCormick: I do not.

Feanil Patel: Hopefully, this will be fast. I'm the transition from Ubuntu 2004 per building and CI to Ubuntu latest For a lot of our libraries and a lot of our repos, has been fairly smooth and where it's failing. It's usually, because we were testing and correctly, rather than there being some sort of

Feanil Patel: specific stuff in there. EDX platform as you are probably, not surprised to learn is perhaps slightly more complicated. And that. It is using. A corner of hash, lib. That relies on settings for open SSL on the OS.

00:35:00

Feanil Patel: which, Require a system setting update. which we would have needed even if we just go from 2004 to 2204. but my question is that?

Feanil Patel: the more I've been thinking about it, the more I think these switch from going to explicit Ubuntu versions to the latest pointer is. Less about. supporting specific versions and more about It all reduces our maintenance burden in all of the places where it doesn't matter. and it'll expose I kind of think of it as the makeup grades happen and then you deal with them when they fail. And for the most part, they just are easy to merge.

Feanil Patel: But since we can't easily do that on the Ubuntu versions having it default to this pointer and having Update that pointer to tell us when it needs for their fixing seems like an okay option in terms of. But it does put us in the situation where When they change that pointer depending on how they do it it might start failing, all of the tests because some underlying thing needs to be fixed.

Feanil Patel: and I'm struggling sort of Between this explicit depth change versus this implicit change and whether Managing this explicitly is valuable enough for us to do the work of needing to remember to do it and coming back to it all the time.

Kyle McCormick: yeah, I think good Jeremy

Feanil Patel: Okay.

Feanil Patel: I'm gonna add one last thing,…

Jeremy Ristau: 

Feanil Patel: which is I'm definitely coming at this, from the perspective of, We have too many things to maintain, and not enough people to do the work. So, I don't want there to be annoying. I'd much rather things tell me when they break, then me sort of manually maintain this always perfectly working system because we don't have the capacity. so that was sort of the last thing I want to say

Kyle McCormick: I think the grid analogy is a good one. Makeup rate is good because when things are running smooth, we just don't think about it. And then when something incompatible happens, we explicitly, make a pin or you make a fix. And I wonder if we can get that same. Goodness, with the Ubuntu.

Kyle McCormick: Do you know if it's possible for us to declare an image alias or just push an image? That's identical to The Bluetooth 2404 and call it open at xabuntu. And use that across repositories.

Feanil Patel: I don't think it is.

Kyle McCormick: And then we would have control of the bump across all repositories.

Feanil Patel: I think we would have to be using our own private workers to be able to do that.

Kyle McCormick: Got it. Bummer.

Feanil Patel: Yeah. That would be useful just to have other aliases. We might be able to.

Feanil Patel: It's a good question we might be able to declare new groups, but I know groups are all for private runners. if we favor extra runners, we could do that. But if we're just using this standard github runners, I don't think we have a lot of control over grouping them or because I looked at this a little bit when we were shifting, the EDX platform. Workers from the ones that you maintains to the Github standard ones. And there's not a lot of controls. We have on the Github action runners

Jeremy Ristau: I mean, if I were selling that product, I would do the same thing. Yeah.

Feanil Patel: Yeah. It's a great upsell.

Jeremy Ristau: Yeah, I think the two they might even be any concerned.

Feanil Patel: but,

Jeremy Ristau: The one thing that popped into my head was around

Jeremy Ristau: So Tim McCormick had thoughts on this too and his thoughts were basically like Python or, libraries totally fine. But idea is that we test on the latest but when there is an upgrade period, we test on our current and the next version. And that's to determine if bugs are specifically related to the next version and not from some other code change or some other version change. So, if we jump to latest, we lose that ability, right? we only test on the newest and…

00:40:00

Feanil Patel: Right.

Jeremy Ristau: whenever an upgrade occurs, which would be silent now, We would have attribution difficulties and cost associated with it. And it's the operators, I think that pay more of that.

Jeremy Ristau: I think. I mean. It's the Ubuntu that runs the tests. No, it…

Feanil Patel: Right. Right.

Jeremy Ristau: but it's Running the tests on Ubuntu. Yes, yes. You spin up different versions and then you run the tests and as long as it's the exact same tests, you get feedback on what is affected by the new version.

Feanil Patel: And you would get this on even if we moved to the latest pointer, you would get informed at test time rather than at runtime of anything that tests could have found.

Jeremy Ristau: Right. Yeah.

Feanil Patel: So it's not as bad Because as long as operators aren't moving to newer versions of Ubuntu without testing their own deployments, which I don't think they will. I don't think this sort of exposes new operational risk.

Jeremy Ristau: You just lose the feedback immediately. When Ubuntu changes their version.

Feanil Patel: You get the feedback immediately, and as soon as when Github changes, that pointer, which is not in fact as soon as the version is available, it's like after some baking period, they've never done it.

Jeremy Ristau: Yeah.

Feanil Patel: So we're gonna learn what that process is for the first time, probably in the next year.

Jeremy Ristau: But we don't continuously run tests, we only run tests on changes and version changes of Ubuntu would not count as changes anymore, right?

Feanil Patel: Right. Right. That would just automatically happen under your change to update a Doc,…

Jeremy Ristau: Yeah.

Feanil Patel: PR might start failing if Ubuntu changed out from underneath you, and that is the risk of this shift for And I'm sort of the mind that that's worth it because We can easily pin back. One things are failing and that's kind of what we do with requirements upgrades.

Feanil Patel: And so we can sort of fix our way forward to unblock ourselves. It's not like it's a permanent blocker. the unblocking is really clear and straightforward but it does prevent us from staying on the Ubuntu 2004 image for much longer than it makes sense. And not resolving issues with modern Ubuntu versions, that might grow up. So, it's sort of a Accelerant.

Jeremy Ristau: And so the cost you pay for that is when there are Ubuntu related incompatibilities. And test me into fail.

Feanil Patel: Right.

Jeremy Ristau: You assume it is because of the change that is going and causing the tests to run and it is difficult to track all the way down to a change version unto. Yeah.

Feanil Patel: That's a fair point. Yeah. And That is definitely the cost of this change.

Jeremy Ristau: Messed up.

Feanil Patel: Yeah, yeah.

Kyle McCormick: Do you see this mostly as a? Risk that maintenance will have to do some extra bug fixing work. Or a risk that a bug is more likely to make it down to site operators.

Feanil Patel: No,…

Jeremy Ristau: Yeah.

Feanil Patel: I think it's.

Kyle McCormick: Or is it both?

Feanil Patel: Yeah for my perspective. I think the bug Opators is gonna make it down to site operators. No matter which of these two strategies we take Because we, yeah.

Kyle McCormick: So it's like a risk of maintenance having to do. some confusing work as Around the time that Github does,…

Feanil Patel: Does this transition?

Kyle McCormick: the Image bump or around the time that someone jumps into a repo that hasn't had a command a long time. And just last time I had to commit was before the ego bone.

Feanil Patel: Right.

Jeremy Ristau: And when we say maintenance or really talking about contributors, right? They're the people who are creating the PR that will eventually fail.

Feanil Patel: Yeah.

Jeremy Ristau: They'll have to look into why and Yeah. Yeah.

Feanil Patel: Right, right. So there's potential contributor churn on something as big as its platform.

Kyle McCormick: In that case. I'm tempted to say. Let's do it. Everywhere. I'm going to latest except Code Jill, right? And

00:45:00

Kyle McCormick: Keep track of when these sort of things happen. And if they happen so much that we say, Wow, that was worse than just pinning a boot to everywhere, then we've learned our lesson. And if not,…

Jeremy Ristau: Do you know…

Kyle McCormick: then we've made things better.

Jeremy Ristau: who the Wii is? In that statement of we should track of it?

Kyle McCormick: I think it's maintenance working group.

Kyle McCormick: I mean. I generally have eyes on a lot of channels and I'll see if people are saying these tests are failing for no reason, there's a bunch of discussion about it and figure out, it's Ubuntu, I guess I'm trusting my ability to pick up. This signal,…

Feanil Patel: Alright.

Kyle McCormick: if this starts happening, I can't guarantee that,

Feanil Patel: Yeah, we also are gonna have an opportunity to observe this problem, like I said, within the next year, So we could just try it and we could just see what the cost is. as a working group looking just have an item to be check in, on this a year from now and I can figure out a way to put that reminder in somewhere that will actually come back to us. and then, It won't be an ambiguous cost. It'll be just very clear sort of what that did for us as a community.

Feanil Patel: And since we're talking about,

Kyle McCormick: Separately, I could see value Ensuring that there's a commit once a week to every repository, which I don't think we would even need to go out of our way to do, it's just a matter of making sure that requirements PIs are getting auto merged or whatever.

Feanil Patel: Yeah. I mean I think that I have been thinking about is for a lot of repos. It would be really useful. If we set up the CI on master to build with a cron along with changes to master Just a weekly build of masters really useful and a lot of our less frequent repos,…

Kyle McCormick: Yeah.

Feanil Patel: don't have it. So that might also be just run CI on the main branch. Whenever there are every week at least,

Feanil Patel: and that sort of helps not just with this but with other issues that crop up when a repo is not active.

Feanil Patel: Do you think this is worth a pilot?

Jeremy Ristau: Let's do it.

Jeremy Ristau: Is the crown job thing like in your backlog.

Feanil Patel: No, that's probably worth adding as a. my God notes.

Jeremy Ristau: But, it's not a huge thing. I'm just wondering if it's already somewhere.

Feanil Patel: no, no it's not but this is something that like In terms of maintainability, we want to sort of add so I'll put it on the Maintenance board backlog somewhere, like, improved maintainability.

Jeremy Ristau: You cool.

Feanil Patel: I think one of the things is that even when we go back to pinning, trying to just do it for ideas as a really nice feels like a decent middle ground for us to fall back to because I feel pretty confident about most of our libraries not having issues. but I think, when we get to the point things like Nx platform, which is using md4, which is a hashing algorithm that Is not considered secure. So open SSL is not allowing it by default. it means that Once the repo gets big enough,…

Jeremy Ristau: On.

Feanil Patel: it will have oddities like that. And old enough I guess.

Kyle McCormick: since you man, I don't know how we would prioritize doing this, but If we could have a list of repos that use a Python package with C extensions. The C extensions are…

Feanil Patel: Right. Yeah.

Kyle McCormick: what is being compiled? on Linux and then Calling into the system. Those are the things that have operating system risk.

Feanil Patel: Yeah, I wonder if there is a

00:50:00

Feanil Patel: which repos are you?

Feanil Patel: I mean, it's not even the library because often the libraries will compile There needed see extensions. It's like

Kyle McCormick: Yeah, or…

Feanil Patel: it's like the core python.

Kyle McCormick: maybe it's not even see extensions, I guess it's system calls. Which cryptography libraries might be doing too.

Feanil Patel: Yeah.

Feanil Patel: Yeah, I'm not sure. I feel like cryptography is bundles everything it needs including maybe live SSL at a version that it can control, but also cryptography does not provide md4. So I can't just switch over to it. There's some of these old things that there's a library that has a pure Python implementation of Md4. And I'm like, do I go to that? But this is the question that I'm figuring out, and You guys, you'll get tagged on the PR so you can have opinions when I get there.

Feanil Patel: but, I suspect that the pure Python version is not fast enough. Because the whole reason we're using MD4 in the situation is that it's faster than MD5. And I'm like if you care that much, Then we probably need the C extension.

Kyle McCormick: Yeah.

Feanil Patel: But I need to go look at the exact thing it does. I just read through some comments but I haven't looked through how it's being used everywhere. I remember seeing it a while back.

Feanil Patel: Okay, This is helpful. I think this is a good. We can try this out and depending on how it goes. I'm happy to sort of fall back but I'm trying to move towards On our maintenance backlog and Just Valuable work and being able to move to newer versions of things that are useful to us.

Feanil Patel: Yeah, exactly.

Kyle McCormick: Last choice,…

Jeremy Ristau: Yeah. It's a good idea.

Kyle McCormick: more feets.

Feanil Patel: Do you guys have any other things you want to chat about otherwise? I think we can call it.

Jeremy Ristau: I had a little bit of a question about the Dev stack thread, but Kyle, you replied,…

Feanil Patel: yeah.

Jeremy Ristau: I think that before right, today, so Good to go.

Jeremy Ristau: Thanks for participating.

Kyle McCormick: Great.

Feanil Patel: Yeah that made sense to me as well Kyle's.

Kyle McCormick: Yeah.

Feanil Patel: I think that's a good strategy. If you need help with the testing the new development Dot PI, please let me know I'm pretty well set up for it as you know.

Kyle McCormick: Yeah, I could definitely use your review.

Feanil Patel: Yeah.

Kyle McCormick: I also need to get a local to open the next IO working.

Feanil Patel: Okay.

Kyle McCormick: And I need to figure out the Yaml thing.

Feanil Patel: That.

Kyle McCormick: I'm actually leaning towards not supporting Yaml, but having a snippet that Too, you can put in their Dev stack file so that yeah,…

Feanil Patel: Yeah, I can help with that snippet already exists in production that pie so we can just crib it from there.

Kyle McCormick: we'll just keep working as it did before.

Kyle McCormick: Yeah.

Jeremy Ristau: Thanks.

Feanil Patel: yeah, yeah, because I think, I would love to drop. most support as a Default in our repositories because I think it's nonsense, but that's a different, larger conversation and dapper and all that fun stuff. Although did you see days recent discussion? Post on plug ability? I think it's not unrelated to what we've discussed before.

Jeremy Ristau: And I think the opposite of Django patterns one.

Kyle McCormick: Pushing EDX Platform to pipi.

Jeremy Ristau: Sorry, yeah.

Feanil Patel: But yeah, yeah, that's the one.

Jeremy Ristau: Or I feel like he was bashing himself at the same time trying to like it's totally fine. we are…

Feanil Patel: Yeah. Right,…

Jeremy Ristau: where we are and it's totally fine.

Feanil Patel: we did what we did and you weren't the only one there.

Jeremy Ristau: Right. Yeah, exactly. Yeah.

Feanil Patel: But yeah, a lot of his thing. other than pushing the PI, I had a bunch of applications about how the applications in the settings are available and set up. And I think that's the part that aligns well with the discussion Kyle, that you and I have had around making things more Django standard in our settings, and our installation of new Third-party Django apps and things like that.

Kyle McCormick: Yeah. Yeah. For sure. I don't know…

Feanil Patel: 

Kyle McCormick: exactly how I feel about exposing all of that ex platform as a Python API to plugins.

Feanil Patel: Shipping.

Kyle McCormick: I don't like it.

Feanil Patel: Yeah, terrible. Yeah.

00:55:00

Kyle McCormick: I'm trying to keep an open mind on it, but I have a lot of hesitations and I ship better response to that.

Jeremy Ristau: Yeah.

Feanil Patel: Yeah. I wonder if there's things we can do in terms of.

Feanil Patel: Runtime import checking to prevent that. Or if it needs to just be like, don't do it. We don't promise anything and then we just break people until they stop doing it.

Kyle McCormick: What is proposing is basically pushing an expert from the pipi so that people can import it at runtime.

Feanil Patel: But I think If we did something And hear the paths that we expect you to import in anything else is not a supported API and if you don't have one, you should make a plan.

Kyle McCormick: Yeah. My heart take is that none of it to support API and shouldn't be but maybe there's a middle ground. That is what you're saying.

Feanil Patel: yeah, I think there are things that are Apis and I think there are things that definitely are not Apis, and if we could make that Clearer. That I think will make a Python EDX platform package viable.

Kyle McCormick: Maybe.

Feanil Patel: You should provide your hot take and then I'll provide my middle ground and then we'll Land where we land.

Feanil Patel: All right.

Kyle McCormick: We'll do.

Feanil Patel: But alright, thank you everybody. I think that's good. Very today,…

Jeremy Ristau: Good one. Okay.

Feanil Patel: I'll see y'all later. Yeah.

Kyle McCormick: Hey everybody.

Meeting ended after 00:56:41 👋

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