edx-platform Maintenance  Sub-Group (2024-06-06 09:05 GMT-4) - Transcript

Attendees

Adolfo Brandes, Awais Qureshi, Chintan Joshi, Feanil Patel, Feanil Patel's Presentation, Jeremy Ristau, Kyle McCormick, Maksim Sokolskiy, Michelle Philbrick, Piotr Surowiec, Robert Raposa, Sarina Canelake, Tim Krones

Transcript

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

Feanil Patel: Okay, and in present that's green.

Robert Raposa: I'm gonna need it a little bigger.

Feanil Patel: Yes, see that okay.

Feanil Patel: There we go. Okay.

Robert Raposa: Thanks.

Feanil Patel: All right. Let's get to it. So yeah tracking work in progress specific genetics platform. So yeah a couple of so we have the full maintenance board, which I've started at least capturing everything on but It's still I would say pretty messy. It's not clear necessarily which things are in Flight who's leading them?

Feanil Patel: and thinking of taking up sort of a perspective similar to what we have on the depper board, which is that like if we don't have a clear contact person we're going to shove it all to the left until it's clear that there's somebody who's actively working on it and that way we can sort of figure out what priorities are in flight.

Robert Raposa: Yeah, I think that.

Feanil Patel: but

Robert Raposa: additional thing though is things that are committed to but not working on we still have ideas of relative priority for some of them even…

Feanil Patel: yeah, yeah. Yeah. Sure.

Robert Raposa: if they're in the future, so

Kyle McCormick: To want to start with the problem statement.

Feanil Patel: Yeah, I mean I think. right now there's no clear place to track all of the maintenance work that we want specific to edx platform.

Feanil Patel: We could track it on existing maintenance or we could start on a new board. We could track it with tags and labels on tickets, but the goal would be to make it clear. I think that one of the core goals is prioritization right like making it clear which thing we want to land next in edx platform especially for people who are close following master

Feanil Patel: Is that capture what you're thinking Robert?

Robert Raposa: yeah so that's one topic. There's also the relationship between this and the same topic not edx platform specific, That would be later and

Feanil Patel: Yeah, what's yeah, let's talk about that in a little bit, but

Robert Raposa: And So I know that this is edx platform specific but there's also a relationship given the size of that X platform. There is a question of whether or…

Feanil Patel: right

Robert Raposa: it would be okay to just Treat those two things as the same. if we solve for the larger one can the platform just fall under that or…

Feanil Patel: right Do we still? All right. Yeah.

Robert Raposa: I don't actually know but I like your problem statement for this one.

Feanil Patel: Yeah, and I guess one of the sort of sub questions in my mind is are there things that are so specific to edx platform that we don't need to coordinate them with the rest of the maintenance community in the community in general. are there changes that are extremely large but still specific to the edx platform org? which would require sort of lots of coordination but not necessarily with other maintenance of other repos and wouldn't sort of trigger the process that we would have to coordinate a hundred repos to do the same thing.

Feanil Patel: and I don't know if I have an obvious answer to that because even when we were trying to get edx platforms python upgrade done that was still 80. transitive dependency repos So, I wonder if we should just bring up this whole problem in about 20 minutes with the entire working group and talk through it as a whole.

Robert Raposa: That sounds good the other piece of this whether it's edx platform or overall is the to you issue. I'll call it to you, but it may be multiple organizations depending on who's doing work of just Being able to prioritize all the work. Together, and not be like, here's two things. That have conflicting deadlines, but we're not actually sure which is more important and…

00:05:00

Kyle McCormick: right

Robert Raposa: and it's because we're not talking about them together and we may be able to

Feanil Patel: Yeah.

Kyle McCormick: yeah, so the way I see it, we have these three different things that need tracking in different ways. one is deprecations and pending upgrades like the idea that We want to remove this thing. It's a Dipper ticket or hey, we need to upgrade to python 11. That's like a Task and then there's the actual tickets that Implement that thing. that's fixing code that's python 311 incompatible or doing the replacement and removal steps of a Dipper and then there's provider the operator side where people need to react to those breaking changes.

Kyle McCormick: I don't have a solution but I think those are

Kyle McCormick: three different types of items. So it makes sense. And right now we're kind of tracking them all and get habits. some of the depart some of the maintenance board So I'm not at all.

Kyle McCormick: For example with python 38 to 311 there was the big upgrade ticket and there was all the sub tickets and then there's the work that to you and every organization needs to do to make sure their environment is running python 311 instead of three eight in that is not something we tracked. and maybe that's okay,…

Feanil Patel: Yeah.

Kyle McCormick: but that's just what I want to call out.

Feanil Patel: I like that a lot. I get so much. I'm like, this is great. I should just make three reviews of this board and make it so that the big epic ticket show up on phase one, which is here are the things we know we need to do. And then their second view could track all of the individual tickets underneath that Etc. Now I like that a lot for the python upgrade. I did do a kind of similar thing, which is that I used the task list to sort of accomplish this Where underneath? on the maintenance board was only a single ticket, which is do the python 312 upgrade and that had do it for all the services and do it for the relevant libraries. And then on the service is one I had I made a bunch of some tickets. And eventually we got to one ticket.

Feanil Patel: For each service that needed to be upgraded and then because edx platform was big enough one ticket for each transitive dependency of edx platform that needed to be upgraded. And so it was as a four or five layer task list. so that got pretty complicated. But I still use that navigation scheme to sort of go find things and figure out what's left and I was able to use it to get its platform upgraded. So some degree that was effective. and I the higher level tickets are still open because

Feanil Patel: The Enterprise repos are not yet upgraded so those are still open and I've been thinking about what to do about that do I care or should I close the ticket? Because the things that we actually prioritized are done or because there's all these Xbox that are not installed by default that are in the open edx work that are still not upgraded for example, and so I haven't quite figured out how to

Feanil Patel: manage the phasing of that the critical stuff is done. The less girls critical stuff is not done but it's also hard to prioritize and it's less.

Feanil Patel: important

Robert Raposa: one other note on the list of three things is in terms of the operator needing to react to Breaking changes. Just noting that there's sort of two subparts of the breaking changes or operators that need to react immediately or preemptively versus the ones that can wait until the next named release.

Feanil Patel: I think there's also like that

Robert Raposa: I was just gonna say I mean that's gonna be different depending on what the breaking change is and whether it really does matter, but it matters smart things.

Feanil Patel: Yeah. Yeah, I think there's also the other version of that. access of that which is like things people need to do before the change lands versus things people need to do after the change lands before further changes can be made right and maybe that second thing is just version of the first thing but for a different change, but I'm thinking of a longer remain sort of multiversion compatible. So the pon still building our dependencies with python 3/8 for edx platform for example is a change where we're upgraded. And it's not but we're not done. until we can actually start building with 311 and

00:10:00

Kyle McCormick: It's almost two and three so doing the work and The Operators reacting are not entirely sequential. It's more like two happens and…

Feanil Patel: all right.

Kyle McCormick: then three happens and then some more of two happens and then some more if we happens.

Feanil Patel: right and…

Kyle McCormick: to interplay

Robert Raposa: I

Feanil Patel: we have to sort of sequence that properly

Robert Raposa: am a related topic which we haven't talked about here much and I don't want to get deeply into but I just want to say where I stand on this and see where you are is, there's the whole

Feanil Patel: right

Feanil Patel: Okay.

Robert Raposa: And this broke and now the people that we're working on it have no idea, our off fonted other things and it's like there's so many other problems that could arise. I just want to acknowledge. Sex I hear it come up every once in a while from various people as…

Feanil Patel: right

Robert Raposa: if it'll just magically make all these problems go away and I don't you will.

Feanil Patel: Yeah, I mean, for I think it's like we will lose some opportunities to be able to find these problems quickly near the changes as a result. I think that definitely is a perspective born out of frustration and out of the inability to sort of land changes when they're ready for sub-groups. But yeah, I totally hear you that it doesn't remove the work.

Robert Raposa: Yeah, yeah. and it's just going to change the frustrations and the problems, And so, okay.

Feanil Patel: Yeah.

Feanil Patel: Yeah, so Jeremy.

Robert Raposa: the

Feanil Patel: old traveling to the notes, but we were talking through the notion of How yeah…

Jeremy Ristau: That I'm there. Yeah, okay.

Feanil Patel: how we track work? Specifically with this notion that we've talked about before which is how do we make prioritization visible and how do we make it sort of like what are the sort of aspects of work tracking that we care about so that we can come up with a solution that will actually solve them.

Feanil Patel: Kyle introduced this idea that we're sort of resting thinking through now perhaps there's these phases that we can think about around deprecation and upgrade deciding to do Doing the thing and then the response to that change happening for operators and providers. So deciding that we need to do the Python 3 upgrade versus the node 20 upgrade. then all of the work to actually do that and then changes the providers need to make to Actually, respond to that if they have their own deployment pipelines that are independent of tutor and the sort of default way of deploying things or even if they have tutor and they need to update to a newer version. Etc

Feanil Patel: I think and we're sort of arriving at two and three doing the work and the provider changes are actually more intermingled than the three-phase view allows for because taking the python 311 upgrade as an example, right? There's we got it so you can run on 311 and then Everything has stopped using the old way long enough for us even to shift the requirements so that they're compiled and 211 and are no longer compatible with the old versions like dropping compatibility. versus and maybe that's a better way of thinking about a Kyle which is rather than making the upgrade two bits. They're one bit where it's like adding compatibility and dropping old compatibility. Maybe we think of those as two separate things which is

00:15:00

Kyle McCormick: Yeah, we can actually even call them expand and contract.

Feanil Patel: And we don't have to do them at the same time necessarily.

Kyle McCormick: .

Feanil Patel: Although the cost of running both at the same time is high. So there's value in doing them pretty close together.

Feanil Patel: but

Jeremy Ristau: the sounds very very similar to replacing Legacy views with mfbs, and it sounded In that conversation like we wanted them to be together. And in this conversation, we're sounding like we want to separate things.

Feanil Patel: I think in that conversation. From my perspective they were both together and separate they're going to be in a named release where both were available and so being able to do the contraction by the next name released wasn't a crazy thing to want to do.

Feanil Patel: With the python 311 upgrade we're kind of in this position where we did a expand and contract all in one named release where we added 311 and dropped three eight in Redwood. And so…

Jeremy Ristau: right

Feanil Patel: what I'm suggesting is maybe we actually want to do something similar to what we want to be doing with that IPS, which is Drop it by the next one. and this might be more feasible in the future where we can add three 12 support but not drop three 11 support immediately because both of them will be Actually supported by the community for a lot longer. We're not in this emergency case where we can keep three eight support, but three eight is going to be dropped by the community later this year. So being more on top of updates might allow us for more flexibility around these expand contracts.

Jeremy Ristau: right

Feanil Patel: We had the MFD case I think is that work should still be planned and scheduled to the contraction should be planned along with the expansion. They just don't have to happen. tly immediately to each other. But we should account for them. Both parts need to be accounted for

Feanil Patel: 

Jeremy Ristau: Okay.

Robert Raposa: Yeah.

Jeremy Ristau: I think I understand the conversation. Is there in Output that already happened or is that where we are?

Feanil Patel: This is where we are you're caught up. although I am liking this expand contract idea though,

Jeremy Ristau: that's

Kyle McCormick: I didn't make it up. I just realized that's what we were talking about.

Feanil Patel: yeah, no, but I'm liking it as a way of approaching the maintenance which is In one named release we add support for. Let's say let's take Django five two, which is coming down the line next year as an example or maybe let's even take note 20 because we're kind of in the middle of it already but we add support for node 20.

Feanil Patel: Yeah, how does that work is for no 20 note is a little bit more finicky word addict having support for both is not as easily possible as it is with python. the package lock

Jeremy Ristau: And you can also live with non-consistent versions longer. right Yeah.

Feanil Patel: in

Jeremy Ristau: Think you can upgrade one MFE and not another MFE.

Feanil Patel: A prayer, right? Yeah. Yeah. That's any more true.

Jeremy Ristau: Which is true?

Feanil Patel: It's more true. I think for the way that to you operate than it is for the way that people who deploy with tutor operate. Because tutor compiles all of the mfe's onto a single instance right now to be able to scale down sufficiently. And this is a problem from a Expand contract perspective. So there's a Gap in different people's expectations

Kyle McCormick: I mean both Twitter both deploys differently and it's on a different release schedule as we've know named releases continuous

Feanil Patel: right

Feanil Patel: right right name released

Kyle McCormick: I'm not expanding and Contracting and there's expanding Contracting on master and there's expanding interacting unnamed releases.

Jeremy Ristau: Yeah.

Feanil Patel: right, and we kind of need to handle both because if we were to do an expanding contract just between a named release that still needs to be coordinated with people who are running off of Master

00:20:00

Robert Raposa: I mean, it seems reasonable to create if ultimately we're talking about. At least experimenting with whether we could make the maintenance board. Show us And do all the things on that board to create the expanding contract as pairs of tickets at the same time and…

Feanil Patel: Good.

Robert Raposa: then to separately get to schedule them and prior so that maybe they will come immediately after each other and…

Feanil Patel: Yeah.

Robert Raposa: maybe something else will come in between the maintenance sport will help us decide.

Feanil Patel: right

Robert Raposa: We don't have to have a fixed rule.

Feanil Patel: Yeah, yeah, we can certainly try it. but I'm trying to think of sort of other. Complexities that we are having thought of yet that we can sort of integrate up front.

Feanil Patel: but

Feanil Patel: that might be a good thing to try is I'm just thinking I I guess we can compile the note we can always be compiling The older version so we would do an npm With node 16, but do an npm CI with node 20.

Feanil Patel: I'm just trying to work through the sort of what the developer experience is like when we have both possibilities available. And How we develop things and what the potential sort of source of Errors can be like we can run CI on both versions and that will sort of catch a lot of things. but it feels like the developer experience becomes very clunky at least on the JS side. I feel like it's easier on the python side, but almost more familiar with the python said

Jeremy Ristau: And a higher level question.

Jeremy Ristau: you still want to support multiple versions of things and on named release boundaries so not a sumac will be python 312 You want to be able to continue to support multiple releases in multiple versions of things in a particular release?

Feanil Patel: right

Feanil Patel: right

Jeremy Ristau: for the foreseeable future and that is mainly to

Jeremy Ristau: promote people to keep up with the named release schedule, but not have to catch up with versioning or what's the main reasoning there?

Feanil Patel: I think it's to allow for some of the value that we get for people who are doing the expand contracts on Master, but for named releases, so it allows for people who are Still using name release boundary releases of the platform but are operating using their own deployment tooling. people who aren't using tutor. So MIT is another good example of this where they use name releases, but they have their own deployment infrastructure. And so would need some prep time there. I'd love to get Peter into bias's input on this.

Kyle McCormick: I mean I can speak directly to it imagine Have a fork of X platform as most providers do. it's written in Python 311. And when an Amber really happens you have two jobs, you have to merge in the new named release changes.

Kyle McCormick: for sumac you'll have to python 3 upgrade that 4 to python 312 if Sumac were incompatible with 311 you would have to do those all at once and if there are any regressions you'd have to completely roll back. as if suback supports python 311 as well, you can merge in the new changes and still have this python 311 code base and then seperately update your code to python 312 so it's just

Jeremy Ristau: Okay, and it's because you want to support inline upgrading as opposed to have sumac running and then have teak running and then do a swap.

Robert Raposa: I

Feanil Patel: I think what the swap is work, I think if you have your own deployment infrastructure or deployment process that isn't automated via tutor. then in order to get a machine up that is running sumac and python 312 you need to update Your configuration your operational stuff ansible your salt stack to be running the right thing and as we've seen to you and updating python. 311 on edx platform that is not usually less trivial than we think. So having the option of being like okay, I shipped python 311 and I found an issue.

00:25:00

Feanil Patel: Roll back just the 311 upgrade but still keep all of the sumac features available. And now let me go make a bug fix. Is that a fix on my stuff in my Plugin or is that a fix-up stream those fixes roll out that fix make sure the fix is okay then roll out 311 gives you a lot more operational flexibility. then if the major upgrades happen at the same time that said this might just be a feature of language upgrades and not something that scales out to something like Django upgrades. For example.

Kyle McCormick: Agreed. Yeah,…

Feanil Patel: 

Kyle McCormick: I don't think we need. To expand and contract for every single change across names releases. I think python is a particularly helpful one and…

Feanil Patel: right

Kyle McCormick: on a Case by case basis we can look. What needs an expand contract and what doesn't? think

Feanil Patel: Right, so that's probably a thing. We want to decide early on in that phase one when we decide to plan an upgrade. We should be like does this need an expand contractor? is this more of it? And I think at that point we can ask the question of does this need an expand contract at the release boundary only at the Master boundary at both and sort of figure out what the plan is at that point.

Feanil Patel: Everyone thanks for catching you all up. we started the conversation talking about how we would track work and prayer organization specific to edx platform, but it's kind of expanded since then so I'm gonna do another summary get everybody back up and then we can sort of continue the conversation which is the sort of core problem statement. We're working with was this idea of it is helpful to have prioritization about which work. is getting done in terms of Maintenance and how do we track all of the work across all of these repos and we've got this maintenance for that we've been using but we started this conversation kind of thinking about if the key is to know what needs to be prioritized especially for operators and providers.

Feanil Patel: When they need to respond to upgrades how do we make that clear? We kind of arrived at this three or four phase notion of any sort of deprecation or upgrade kind of has a decision like we are going to do this. then some sort of action phase where we're actually making the changes and Landing them and then

Feanil Patel: response to that change by operators are providers. So taking the Python 3 11 upgrade for an example. We sort of decided to do it. We made all the changes and then at some point operators if they're not using tutor still need to update any of their operational tooling to use Python 311 actually run the platform, right?

Feanil Patel: we kind of went maybe it's a four-phase thing where there's both an expansion and contraction phase where we add support for 311 but don't remove 3/8 support and then later remove 311 3/8 support as a separate step.

Feanil Patel: And we do that across release boundaries. So Redwood supports both three eight and three 11. And we dropped three eight by sumac for example.

Feanil Patel: which is effectively what is happening, but being more

Feanil Patel: deliberate about it

Kyle McCormick: And one thing we touched on is that this ties in with deprecate the debit process. It's not just upgrades because when we deprecate something we announced the deprecation. We expand that is adding a replacement and then operators probably migrate to their placement. And then the contraction is the removal of the old thing. So, I think we're seeing this parallel between upgrades and deprecations.

Kyle McCormick: really any breaking change we could be looking at in this working group.

Feanil Patel: coming back to it. just jump into the conversation if you have any thoughts.

Feanil Patel: But going back to it. I think that when we make the decision for the deciding decision that phase one decision that we should do the note 20 upgrade. That's when I think we probably want to start having the conversation of okay, would it like what are the phases of this? Is there an expand contract for this or not?

00:30:00

Feanil Patel: and it sounds like maybe for most things there would just be the upgrade happens sumac will have Django 42

Feanil Patel: change will have landed sometime between here and there. On master and gotten shipped to anybody who's following master.

Feanil Patel: and then there are the other things like The language upgrades or my SQL upgrades for example or Mongo upgrades which sort of can happen so maybe this is actually a question of anything that is a supporting technology and we are creating the version of that.

Feanil Patel: Because those are things where there's operational impact on providers where they have to take action. Whereas code changes that land for code base are things that just Can easily be a move forward right?

Kyle McCormick: I'm not sure I follow.

Feanil Patel: if the change is in the code that we are shipping then it is just an incremental change and it is a thing where it's sumac just has Django. five two there's no way to run it with both really but for things that are like redis if we are the redist library changed. and the new version of the library drops support now all of a sudden that Deliverance Library update is actually like an infrastructure related update and that requires operators to have more awareness and they need to take action because those are parts of the system that we don't control as the open edx. Platform those are things that we depend on. But their libraries that help us connect to those things like if we had the SQL Library drop support from my SQL.

Feanil Patel: Eight zero because it only supports eight four. That would be a change that would require a multi-phase update.

Kyle McCormick: Not sure I think it to me depends on how complex the migration is. And that I mean if we're talking long-term modulestory to learning core migration, that'll be based over multiple releases. Even though it's an open edx thing.

Feanil Patel: Yeah. no, I'm talking more like the latest version of the platform won't support my SQL 8, but you're running my SQL 8 and you need to upgrade to my SQL 84. that's an operational change you have to make and I'd love for there to be a version of our code base that work with those eight zero and eight four where possible. Because that's infrastructure that you have to change that. I can't make you change that until you have time for that. Whereas

Kyle McCormick: The same is true plugins though. if you're an open edx plugin and depends on an open edx library, and we've made it.

Kyle McCormick: If we don't have an intermediate phase where both versions of the plugin API are supported then we've broken plugins across releases.

Feanil Patel: get I think yeah, but I would argue that that's actually correct and we should have a version that supports both the Old and New interface. We had this conversation with the front and stuff right Adolfo where we were saying even though there was an implicit interface. We should support the implicit and the new explicit interface for a release so that we can allow people time to switch over without breaking them immediately when they upgrade to a new version. It makes the upgrade path smoother if they don't have to be broken immediately when they go to the new version. then they don't get any of the benefits of the new version and it's much easier to stay on the old version and then we get people that are still running dogwood.

Adolfo Brandes: Yep.

Feanil Patel: so I think when we break interfaces, we have to treat that very seriously and even if they were historically implicit interfaces, and we want to get rid of them.

Adolfo Brandes: Yeah, plus it's not forever, about a release or…

Feanil Patel: Yeah.

Adolfo Brandes: two or A year, roughly we're talking.

Feanil Patel: I'm happy to give people time and if people say give me a reasonable time frame that they want for things. I'm happy to change my mind, but like we should say a release by default and if we think that people need more time, we should adjust it, but we should give people at least a release if we're removing an interface that they're relying on for plugins or front ends or anything. I think that's a reasonable amount of time.

00:35:00

Feanil Patel: right, so that's actually

Feanil Patel: that's a great question. I would love for thoughts from the couple of you that run on Master on that I think six months on Master feels like a much longer time, but also planning takes time. So

Feanil Patel: yeah.

Adolfo Brandes: But I don't know maybe that's too loose.

Robert Raposa: but

Feanil Patel: No. go for

Robert Raposa: I was just going to say There's two sides to this relationship. And so the maintainer might be on the side that cares about when master. gets upgraded or not and the maintainer might be on the other side where they're the sooner the better because then I don't have to maintain it and it's some other group that actually cares about when Master changes so it's

Adolfo Brandes: good point

Robert Raposa: and I think that the six-month thing. is a reasonable I don't think that needs to be the rule but something to keep in mind that it works differently, whether it's name releases or master and that just because it's Master doesn't mean time isn't needed but I think that relates back to the earlier question, which is And how can we maybe get more of these things on the board and give relative priorities so that we can say of this one? Can land in two months or one month or whatever because all of the people that are affected are able to actually do what is necessary.

Jeremy Ristau: I think from my perspective. Offering people who are on Master the same. SLA as you offer named release people feels like the right thing. It doesn't always have to be months. But if you get six months of boundary that should be true for the entire community. It shouldn't be like, you only get four weeks if you run on Master, but you get six months. If you run a named release to me, it feels like you offer it like That's your standard Behavior. And the people who run on Master hopefully can react fast enough so that it isn't six months for everything that you want to land. And if you have the prioritization of things that are trying to be landed and I think that also aids people who are running on Master to be able to prepare appropriately for the things that you want to land earlier.

Jeremy Ristau: that's my opinion. This don't make up a new set of rules for people who are on Master versus not from this kind of.

Feanil Patel: I will push back a little bit only in Devil's Advocate mode not necessarily disagreeing with you for the actual implementation. That's what it is as a project. I think we can say which things we support and we should be thoughtful about do we support master and named releases in the long term? that is a question that we should ask. I think there's a value in supporting both master and name releases and having I would love a couple of operators who are running on Master instead of the one that I'm aware of and in that case supporting master, I think becomes more valuable to us because we get a lot of different. Feedback and perspectives on what's buggy and what's breaking.

00:40:00

Adolfo Brandes: not to get too into the ways I know of a big projects that support both in some way she performed…

Feanil Patel: but We don't have to do it that way. we're not required to say that we support Master for everybody as a functional working version. It's just that we currently do.

Adolfo Brandes: but usually When Master is also stable right as opposed to Masters unstable.

Feanil Patel: That's okay, but we can change our mind about that. We just have to do it as a community and…

Feanil Patel: think through the consequences of that.

Adolfo Brandes: there's very heavy investment into CI and…

Adolfo Brandes: and testing so that the risk of landing something that doesn't work Masters very small or…

Feanil Patel: 

Adolfo Brandes: as mitigated as possible anyway.

Feanil Patel: Or…

Adolfo Brandes: yes first

Feanil Patel: anything like it's not crazy for platforms to have release versions and then Master be slightly more unstable. Django is a perfect example of this where even though Django has really good testing and a lot of people using it they still use releases is what you're expected to use. So there are a lot of ways of operating and we shouldn't necessarily think that the way we're doing it right now is the only way but yeah for now given that we have operators on master and unnamed releases, I think having Separate rules is more annoying.

Feanil Patel: and so having sort of the same Expected I think six months is a pretty good expectation.

Adolfo Brandes: How much of this is coded into the Dapper. Oep already. I'm just curious. I don't have it open or…

Feanil Patel: I love the idea of being like,…

Adolfo Brandes: anything. I'm sure part of the process establishing a time frame for each deprecation, right?

Feanil Patel: okay, we know who the operators are. Can we sequence this work faster or sooner by communicating? What is coming down the line? can we get it? So that lands in a month because we knew about it nine months ahead of time seems like a great place for us to sort of reach in terms of Maintenance planning.

Adolfo Brandes: Okay.

Adolfo Brandes: Great.

Feanil Patel: get yeah, so I would say it's part of the implicit rules and not part of the explicit rules yet.

Feanil Patel: because when you fill out a Decker you say which name release it's going away in and so the named release aspects are coded in but the master aspects aren't and I think actually that's what's led to some of the confusion around Dippers and Landing is that we haven't made this explicit understanding that…

Adolfo Brandes: Yeah.

Feanil Patel: what we need to make sure that getting Master up to this new version and cleaning up afterwards are all part of the same work.

Feanil Patel: and so people I think and historically are as a project our history in terms of cleaning up things…

Adolfo Brandes: We got rid of coffee script.

Feanil Patel: where we made new versions is terrible

Feanil Patel: I expect us Kyle you're sort of waving and no. No, it's just terrible. we left Yeah.

Sarina Canelake: really excited but my instructor dashboard pages that are We know not great.

Feanil Patel: left we still have jQuery running around at not even the latest major version yeah, so

Sarina Canelake: still exist I was about to unmute to add something. So thanks for calling on me. I think one of the things is the sort of the context of the Decker oep when asking that question we were adding in…

Feanil Patel: we got rid of coffee script and it took three and a half years in Serena leaving the company once to do it.

Sarina Canelake: what named release something was going to be Depot of because I think fundamentally at the time that ope was written Edx is deprecating things, but the community doesn't know about it.

Sarina Canelake: So the first round of that oep was…

Adolfo Brandes: but

Sarina Canelake: how is edx communicating outwards? And so that's why there is the focus on the named release field is because that was the mechanism by which to communicate with the community. And now as the community is evolving need to Jeremy's Point we've got People in the community now wanting to Depot things and you need to know because they're running a top master. So there's this other direction of communication. That's just not quite there in the oep just simply because that wasn't the historical context in which it was written.

00:45:00

Feanil Patel: That's really good new ones.

Robert Raposa: just Yeah,…

Feanil Patel: Thanks for you.

Robert Raposa: and just to add a little bit more context to originally it was just Target dates with give at least two weeks kind of thing, but there was nothing and then we switched to name releases even just to simplify that and go okay,…

Feanil Patel: right

Robert Raposa: and that's what started going to the sixth month thing. But we have nothing explicit or even agreed upon implicit. I would say on the master side which is why we're doing name releases, but if someone proposes something that's Two weeks before the named release. there's nothing to stop anyone from saying. Yeah, let's just do that quickly. So

Robert Raposa: I think making That explicit sounds great.

Feanil Patel: so yeah.

Feanil Patel: Both to think about sort of where and how to make That explicit I think. I'm not at least write it down in here as a decision.

Robert Raposa: And also noting that Dipper is just one of the pipes of things but it'd be great to have the same rule for what we said above any breaking changes for operators.

Adolfo Brandes: Definitely. I was thinking just that whenever breaking change for operators happened wherever the source it's gonna require a Decker somewhere, right?

Kyle McCormick: No, I don't think we need to deprecate every breaking change. But I do think it's worth thinking about. in terms of having a six-month expanded phase for things for breaking changes by default

Kyle McCormick: We didn't deprecate python 3/8 support. And let's…

Feanil Patel: right

Kyle McCormick: unless that's…

Adolfo Brandes: That's a good.

Kyle McCormick: how we want. I mean maybe we could do breaking changes like that.

Feanil Patel: right, but we could

Adolfo Brandes: Shot or…

Adolfo Brandes: I'm curious. I don't think I have an opinion when should that we have Dappers first off like this and when shouldn't we?

Robert Raposa: I mean, It's definitely a possible way to communicate. that type of Breaking chain,…

Kyle McCormick: Yeah.

Feanil Patel: right

Robert Raposa: so it's a possible solution.

Kyle McCormick: I think conceptually run the same page,…

Adolfo Brandes: Because it feels to me.

Kyle McCormick: but it's a matter of how do we want to communicate this? we want to take what labels we want on the tickets. That's what I think.

Feanil Patel: yeah, I mean there's also a mechanics of it right if

Feanil Patel: If we had said that we landed three Eleven on. May

Feanil Patel: May 3rd, probably And we wanted six months of python 3/8. Does that mean that I think for one it puts us past 3/8 supported lifetime in this case, but if we did that. at that six month mark if I couldn't remove Python 3 now it would be upset. right it sort of puts more of a requirement on that being done by then. And so if the work didn't get done by operators, that would be much less willing to be lenient about it even for master.

Feanil Patel: this is just me representing how my emotions would go not necessarily how things should work but when we put dates on things and make that kind of Promise It becomes more like, people hate losing stuff more than they like gaining stuff. So it's important to keep in mind some of that cost. In terms of making some of these things more deadlines. If the deadlines are going to move.

Adolfo Brandes: so just to add to that a little bit another problem of having a let's say we make it explicit right? They're going to be a ton of exceptions.

Adolfo Brandes: so some of them really small it's like if you run into something this is so small It's a Small Change. why do we have to wait six months, right?

Adolfo Brandes: I'm just saying we should talk about maybe most of the cases as we decide this. maybe in a PR to do the oep or…

Feanil Patel: Yeah.

00:50:00

Adolfo Brandes: an ADR or something where we can bring up all the different scenarios. just so we don't. paint ourselves into a corner

Feanil Patel: Go for Robert.

Feanil Patel: right right

Feanil Patel: Yeah. I think I've reworded the decision at the bottom to an agreed upon extension phase parentheses, maybe six months similar to releases because I think that we want to try this out before we commit to it exact number and get a better feel for what the reality of the situation is.

Feanil Patel: Because I think it looks similar to that right on the named release side. Sometimes one named release might not be enough.

Feanil Patel: fair enough

Feanil Patel: That's fair. Maybe six months as default.

Jeremy Ristau: yeah, I mean It's a lot like sending an email saying take a look at this before the end of the week and at the end of the week, it's going whether you've given your feedback or not or the edx platforms CC Channel where people put in their PRS and they say in 30 minutes. I'm gonna merge this unless I get an acknowledgment beforehand. I think this is just a much much larger scale version of those kinds of behaviors. I would say…

Feanil Patel: did

Jeremy Ristau: if it's been six months and people who deploy off of Master haven't reacted that' That's their problem. But if it's been six days, that's everyone's problem. Right? And so you…

Feanil Patel: Yeah.

Jeremy Ristau: I think six months is more than enough time to give people the space they need to react and a healthy way and if they don't react in a healthy way, it's not the maintenance problem.

Jeremy Ristau: And that's me knowing that I'm the person who's gonna have the most problems. I feel if I run your side I wouldn't say any more than six months. It's just the same amount of time you give everybody yeah.

Feanil Patel: That fair enough. And with conversations would be like hey in six months. I'm gonna need to do these three things that our company can exist in seven months. Maybe we've changed strategies a little bit.

Jeremy Ristau: Ation, yeah. Yeah exceptions about both ways. Yeah, absolutely.

Feanil Patel: Yeah, yeah. But I like that I like six months as a default. Let's play with that. Let's try that out for a couple of these we're possible.

Feanil Patel: We are at time for this week. Maybe next week. We can try to exercise this with the node 20 planning because we're still early enough in the planning that we should sort of talk about. Does it make sense for the new 20 upgrade? What makes sense in terms of phasing? and then actually try to apply it for that upgrade, but if people think Yeah. Let's see a thumbs up Adolfo.

Adolfo Brandes: works for me

Feanil Patel: And I'm gonna continue to work on this board and see if we can actually last item the maintenance or currently has a bunch of two you specific team views, which I'm going to drop just so that there's less things that I don't care about on there. But if those are important to you, please let me know.

Feanil Patel: I don't think they're really being used today. So I'm not sure how much value they're providing. So I'll clean that up and hopefully that'll make it easier to see what's make the maintenance more usable for more people.

Feanil Patel: Thank you everybody. Have a good rest of your day.

Adolfo Brandes: Okay.

Meeting ended after 00:54:40 👋