 Everybody I am Matthew Miller the Fedora project leader and this is a Fedora Council video meeting as I always say but maybe it's the first one you're watching. We try not to conduct our business in meetings at all. We try to do it asynchronously because we're a global community that is hard to get together for one meeting but we also find value in the high bandwidth connections of meetings and occasionally in actually literal high bandwidth video meetings where we can talk back and forth. Particularly about once a month we do a thing where we pick an interesting section of the project or something that needs help or something we want to focus on or something that's going on that we want we invite members of that part of the project to come and give us a presentation what they're doing. Kind of basic thing is what's going on where are there problems where you could use help what the council could do for you and you know other future plans that sub project. So today we have Steven Gallagher representing ELN which is sort of new sub project in Fedora that's related to the production of Red Hat Enterprise Linux and I will let Steven give you the details for that. Welcome Steven. Thanks for having me Matthew. So first of all yes I'm going to introduce Fedora ELN to those of you who either haven't heard about it yet or don't know much about it. As a start we generally do try to refer to it always as Fedora ELN because it is very important to us that this is part of the Fedora project and not a third party not a rel project or whatnot so let me just I'll make sure I put that in my what my rules for saying words I guess that part of my brain. So I hope my presentation is coming along for the recording. Yep looks good. All right so as as we like to refer to it in the in the ELN SIG we call it pulling putting the rel ish on the beefy miracle so some of the videos may not be familiar with that old joke but we once had a Fedora release that whose codename was beefy miracle and it became kind of a meme of its own in the Fedora community. So when we came up with this idea to start actively developing rel in Fedora more and more clearly delineated the term relish kind of came naturally. So let me so let me talk a little bit first about the history of how Fedora become it became rel. So with rel 8 as my example and for and for rel's prior to that what we would generally do is we would stop after a particular Fedora release where we had internally at Red Hat decided okay we're going to start we're going to halt here in the end and prepared this to be the next Red Hat Enterprise Linux. Generally we would we would pick a Fedora release on its release day we would then we would then take a snapshot essentially of of disk it for all of the packages that we intended to have in Red Hat Enterprise Linux copy that internally and then spend about the next six months sometimes up to up to nine months preparing to bootstrap rel or not preparing to but actively trying to bootstrap rel from that Fedora release which was extremely time-consuming and very very painful for those of us me who had to do it and a large a large part of that was because you know Fedora being what it is it's always looking to the future it's always expanding it always has the newest and latest tools and as think as these things go sometimes it's not possible to build it's build itself from its current state so that was not a great situation because yeah it took six nine months a good chunk of time to to turn Fedora into something that we could use to start to hand to the developers to start building rel so we wanted and now as of rel 8 they announced that future versions of rel rel 9 which is in beta right now and and onwards we're going to be coming out every three years on a schedule not when we get not when it's done as was in the past we would slip and slip and slip and it would just you know the gap between rel 7 and rel 8 was well I'm sure some of you have have raised children into call into school age in that time so with only three years to with only three years to work with spending six months just getting it started it was not going to work so a few of us most mostly alexandra federova and myself and a couple of others in the in the bootstrapping team sat down and tried to figure out how can we shorten that bootstrapping time how can we make that work better and at some point and I don't actually remember which of us initially had the idea but we decided that the easiest thing to do would be to never stop bootstrapping essentially take a take a project create a project in fedora land whose purpose was to continuously bootstrap and fries linux so when and so when we started this we gave it we gave it a code name project that eventually turned it turned into eln it was El Nino which is which was a multi-layered set of reference references and in jokes of course el l l is the distribution tag for rel and sento s for enterprise linux Nino is the is the Spanish word for a male child so there the implication in that was that this is the project that is the immature version of what will grow up into enterprise linux and then also el Nino is a type of weather pattern that occurs every three or four years and pretty much always brings storms in with it so I think that reference should be fairly obvious a lot of a lot of furious activity tends to happen in both the fedora and rel communities right around the time that we are heading towards a release so what is eln itself it's a it's no longer el Nino we we kind of back renamed it to be enterprise linux next and it's an attempt to make an early early preview kind of a kind of an alpha but more of a pre alpha of what the next major you know a major version of rel rel 10 rel 11 rel 12 rel 12 hopefully I'll be retired by rel 13 will look like and maintain and then try to maintain those changes and keep them up to date making sure that they build in fedora so how are we doing this well for the a great many packages actually just build as is against rel which is great those are the easy ones but there are a number of packages that are maintained in in fedora that are conditionalized so that they would build in rel or apple it's differently than they would build in fedora now for a lot of so some of the cases for that might be you might be in rel in fedora you're okay with including experimental or unstable plugins or optional optional features that you know a niche group of people might use but in rel you know you maybe just want to maintain only the pieces that the majority of people will use and that aren't likely to break and cause a lot of support costs so maybe you can conditionalize your package for that maybe you conditionalize it to reduce your dependencies which is a big thing in rel because we the every package we ship we have to support that red hat so reducing that number is always a goal we also build sometimes in enterprise linux with different compiler baselines and different op the compiler optimizations or or similar functionality so we would so in eln we always track sometimes ahead of the intended baselines and optimizations for for red hat enterprise linux and another very common one is that with eln and rel oftentimes we try to package pre-built documentation which is kind which is in general a no-no in fedora because we always want to make sure that it's up to date and regenerated but in in red hat oftentimes the document documentation builds in fedora are responsible for some of the longest dependency chains the distribution I mean if you were to look at the dependency chain of any basic python module without building its documentation and the dependency chain of it when you have pythons when you have python sphinx documentation built it is three orders of magnitude longer so that's one of those things that we very very aggressively try to remove from rel and so we can start we can start doing some of that months and months maybe even years in advance when we do it in now enterprise in eln red hat eln that's fedora eln goodness so that allows us to make a bunch of uh just rel specific ish changes but for the most part we try not to disrupt fedora itself we do a we do a series of rebuilds through our through the same koji instance but we do them triggered by a bot that follow that follows along and does not uh it does not uh block fedora packages if the eln package is not building or is or is failing its tests so that we don't interest so that we don't significantly interfere with or delay the development of fedora but in general any package that is in the what we've declared the rel content set is rebuilt automatically in from fedora rawhide every time a fedora rawhide build is triggered is completed uh or more to the point it's actually whenever that build is tagged into the uh candidate tag for or for inclusion in the next compose uh don't need to go into the specifics of that i suppose um lost my train of thought for a moment but uh so what a eln is also essentially the point it with the the point from which we will fork uh the next version of centOS stream which is where which is the open environment where we will uh where uh red hat will do development for red hat enterprises linux n plus one in fedora is this uh what when we were doing this uh in fedora 30 sorry for rel 9 we broke inheritance at the final freeze of fedora 34 so we had a stable fixed set of a set of uh commits that we could then say okay these are going to get moved into the centOS stream uh discrete repositories uh trimmed for sort of uh legal reasons um the history rather is trimmed a bit so that we don't have to get uh so that we uh that's complicated i should probably leave that one out um so during that process uh if you were if you were working towards rel 9 you would build you would do your work on rawhide first rawhide for most of the time until we got to fedora 34 branched and then people who were trying to target to rel would be working on fedora 34 branched for a bit about a month month and a half and then switch over to centOS stream 9 well it did turn out that we uh that that was an awful lot of churn and conf and confusion rained from that so starting with uh rel 10 which we intend intend and expect to branch from fedora 40 we're going to do the uh we're going to do the centOS stream fork off at the at the fedora 40 branch point as opposed to the later freeze uh so the point is the point there being will be from from now on any non-centOS stream you know directly rel work will go it will be going into rawhide and only rawhide will be it will be will need uh dealt with until we get to centOS stream um eln will always track rawhide we've already uh moved on uh to developing rel 10 eln we've got we've made some uh interesting progress there and we are experimenting with a variety of of things including but not limited to the x8664 v3 compiler baseline some some new compiler flags related to link time optimization and similar and we're also we're also monitoring through the the content resolver service um how our dependency trees are growing or or shrinking and trying to keep that headed towards the the smaller side of things but we are generally these days we have we have a compose most days that succeeds um every once in a while like just this past week we had a an extended period where uh the where eln's compose was broken for esoteric reasons but uh in general it's available uh we've got from uh dato from amazon from uh i believe we had some from ibm some from i think i think we had somebody from lenovo who have all been actively working with us to get uh new functionality and tweaks into the uh eln systems so it's been uh fairly effective it's been fairly it's been uh a pleasure to work with everyone and i think that pretty much sums up the explanation so maybe we should next move on to just any questions and what uh what you want and more you might might want to know about uh elan so i'm going to stop sharing my screen because with blue jeans that's the only way i can see your faces when you ask questions still being shared there we go and i put us all into gallery view you can see we've got a small audience uh today but i think we'll we'll put this online so more people can see it as well i've got a couple questions does anyone else have ones to start i'll throw one out there so is eln usable as like uh you know you could do we build a like an installer compose and actually install it on a machine that like an anti-goal for the project so we do produce an installable and installable compose i have on a couple of occasions installed it into a virtual machine successfully this it is not at this time an active goal to make sure that that that is necessarily installable we generally stop at present because we by lack of resources we stop at is it capable of booting the installer that's that's our minimum the viable product as far as i'm concerned uh whether it successfully installs that's that's a problem that uh that the that really requires a subject matter expert to deal with there there are a number of users though that have gone to from a fedora base to eln you know done a system upgrade online that way which tends to kind of work originally that's what we were recommending people do as well if they you know if they wanted to work on it with a container we never i or i never at least expected anyone to attempt this on their laptop and i'm both surprised and pleased by the number of them that have actually pulled that off so the only note for people hearing this and thinking they might want to try that is they probably should start with a minimal fedora install and then move over from there so you're not bringing in a bunch of depths and end up with a hybrid system good advice a frankenstein system i i've got a couple like smaller technical questions and then some big questions uh the first one highly technical is does the eln bill bot have some sort of punny name and if not why not given everything else um it actually does i thought so but it we're actually using the same the same build bot that that mirrors content from centOS stream to rel internally so it and it is referred to as the distro baker um all right so we which which was so named because uh as kind of a joke that stuck the bootstrapping team internal to red hat for rel 8 named it named itself the bakery so naturally when we came when we had to build a bot it became the distro baker that that's better than a lot of possible alternatives along those lines um the other question this one actually is more technical uh so there are these rel conditionals basically choices in packages that are rel specific um is there a process to review those as things go forward and see if they were there for some you know reason related to some weird thing in you know rel 6 and remove and clean those up is that part of eln scope it is definitely in scope is not something we have had the resources to do yet um it generally speaking that's going to be a task that we're going to need the maintainer to be involved with and our so far what we've been our focus has been heavily on making sure that it is stabilized enough that uh it's that that maintainers could start to care about it more right now right now our best our best intention is to make sure that the the maintainer doesn't notice that we're doing it you know it doesn't it doesn't negatively impact them we then we want to move to having them take advantage of it for improving for improving their ability to get something into rel and actually segues into my other questions which is um when this project was you talked about and proposed one of the goals i know was to make sure there were no downsides or minimal downsides for average fedora linux packages who might not care about rel um in practice how was that worked out like what you have people seen disruptions have there been things that need to be adjusted there have been there have been some adjust adjustments made uh mostly because we just didn't realize in some cases that people would get notifications on certain events and we had to we had to work with rel engine to to reduce that fire hose um but for the most part we've actually been pretty successful it was a lot of notifications i did use the word fire hose it's not um but that was that was a definitely a bug to be worked out not a uh design choice so on the other side of that same coin uh are there advantages for fedora maintainers who don't necessarily care about rel does there a benefit or is it sort of um neutral is the best we can hope for well i guess it's it partially depends on whether or not they don't care about rel but does rel care about them uh because if it's you know if we've got a package for something that is central to rel like for example bash that isn't maintained by a red hat maintainer that way i mean bash probably is i haven't looked i'm just pulling a name out of a hat but uh then it's entirely possible that elad will become relevant to them if only because rel maintainers will start make proposing or pushing changes into it uh directly but a direct benefit to them i think it's hard i think it's hard to uh claim one uh off the cuff i'd have to give that some more thought but i don't but in general i think the best we can hope for is not antagonizing anyone all right fair enough i mean there there is the advantage of of rel maintainers suddenly actually care about fedora you know in that aspect and and they do you know they'll go and fix bugs that maybe you haven't had time to get to where those things upstream because they're going to affect rel as well um the question remains is it you know how is that going to last right it's obviously died off quite a bit with the current rel cycle you know before we've always had in fedora before every rel release is branched we suddenly have interest from rel maintainers and developers and then they disappear i think that the process is going to be better now because there's notification and things like that but how much better remains to be and how much does that end up benefiting fedora and a piece of that too going to be working to change the the culture inside of red hat to be to care more about that because instead of instead of before it was a hand wavy eventually for the fedora will become something you care about it's now we're trying to get people to recognize fedora eln as being this is what you need to be caring about because this specific thing is what's going to come to bite you later so fix it now and save yourself a lot of headaches yeah that intermittent caring has always been a problem where you know a lot of times your red hat doesn't even pay it for a while hadn't paid attention for like four years and then suddenly cared a whole lot maybe in a kind of overbearing way sometimes so hopefully this will reduce that but i guess that i recall a certain pizza metaphor involved there right this this does thus bakery right this but this goes yeah actually we're doing a good job of leading into the questions that i noted so one of the things i've concerned about is that you mentioned branching to eln at the f40 fork so it's about nine months from that half when that happens until the f40 release happens so once that is branched how do you keep people's attention on on the fedora side of things when you know rel demands are coming on the other side how to realistically a lot of them a lot of there will probably be a few six months dippin in activity there but not necessarily because there are plenty of packages and plenty of maintenance and rel land that are going to be still trying to trying to keep their fedora stuff in sync because they want to catch they want to pull something in past the f40 you know there there i'm sure that plenty of stuff that happened that will still happen in the kernel just as justin can attest and i'm sure that there are plenty of other packages too that will continue to be developed on rawhide and may yet be pulled over and so caring about it in rawhide means that the that that's what that pulling that in down the line becomes much easier the kernel is typically not part of the branch and it never has been uh every time they've branched fedora for a rail release they branch user space but then kernel keeps going they said a target upstream kernel version that they're going to fork over who's what happened this time it was months after and does that rel kernel now come derived from the fedora kernel the source rpm for uh rawhide will build a rel kernel and will build a um so when it's built against dln it builds a rel kernel it's completely different so that's actually a big change from the kernel in i even up to rel eight right uh yes rel seven for sure where the kernel actually was kind of disconnected from fedora completely yeah so they they used to branch um they've branched the fedora kernel and then you know kind of maintain it completely separately at that point uh and at that point they may or may not pick up some of the spec changes and those things we've made one of the advantages to this setup is now you know all the spec changes everything is happening in arc which is the elin kernel and and fedora kernel and there there are some disadvantages to it from a fedora standpoint and some advantages but the disadvantages are not so bad we know put a pretty good trade off so there are patches that are rel specific and have no relevance to fedora by policy now those are all hidden behind a uh config rel differences and so even though the code is there um unless you are building a rel kernel it doesn't actually um you know the code path taken isn't there and then when we branch for fedora stable releases i go through and remove those things just because so much of our support model given the the single maintainer uh of kernel is you you've got to be able to go upstream so people need to be able to apply patches that they're given um or uh yeah revert patches things like that without having a bunch of of noise in the way that might especially non-developers make it more difficult for them to interact with upstream one quick and i should wait pause i'm going to interject before you interjection haha i should introduce justin here who is fedora kernel maintainer for a very long time and does a lot of other things and has done a lot of other things in fedora including being one of the founding members of the elensig uh i was just going to mention justin did i think twice during that talk that statement you mentioned arc uh without without a preamble so for the benefit of anyone who isn't familiar with that acronym you might want to clarify right so that that acronym and that actually probably should be changed at some points there's been a lot of discussion about it it's supposed to stand for always ready kernel um and it started as an internal rel thing and uh you know they wanted to have essentially a modern kernel turns out it's it's hard to keep up and you're not doing that day to day and we were already doing it for rawhide so it kind of made sense there and like said there have been a bunch of advantages to that setup too you know it's we do have kernel developers actively looking at things you know pretty consistent even after the rel 9 kernels branch there are still people there one of the ways that that's done is because the rel configs are there they have to be reviewed as they come in and so that gets people looking at at the new things coming in for fedora everything is the configs are kept differently and there are several things in there that allow me to do builds for fedora without having to wait for rel process so like if we have a compile bug or something of that nature that that really has to be fixed i've got a patch for it i don't have to wait to get permission to put it in we have a process where essentially it goes into disk it so we can build with it but it doesn't go into the tree until it gets approved that makes sense um uh steven you mentioned uh that the fork kind of goes it goes it flows to centOS stream at some point um can you talk a little bit more about the relationship is that kind of a handoff to centOS stream how does the build or bakery team stay involved on both sides there how does that so the yes uh the bake well the former the team formerly known as the bakery um now uh generally known as the uh emerging rel team uh works on the fedora side uh our you know uh our uh avatar is the fedora eln and we are also heavily involved with the centOS stream project and in fact where we contribute to on both sides we kind of straddle that line so yeah uh we we spent uh i'd say probably about eight months uh smoothing the way for uh for rel rel nine over on that side for shifting our our primary focus again back to uh eln to prep for rel ten i guess so uh is that focus likely to be a wave between the two projects of focus or is there um it's going to be a wave in the same sense that the uh the waves crashing on the beach are a wave some of them will be larger some of them will be smaller and uh and they will be entirely unpredictable okay fair enough um it will not be a nice clean wave so what about fedora server which is something i you know is is dear to you um when we set that up one of the things we wanted to do was make that kind of a clear upstream for the rel server product um is that still kind of in the plans is and how does you know the the emerging rel team work with with you know the fedora server working group um and how does that all connect so you're right that that was the initial intention of the fedora server group and ultimately it i'll be frank we failed in large part because we didn't have something like eln uh at the time or have even the the beginnings of an idea for something like eln uh to to work from we didn't have the ability to change our configuration specifically to build the fedora server we had we were working under the same constraints that we were before which was we can make small configuration changes but not package level changes uh to to what we shipped in fedora server um with that with that plus the fact that that back at that time we were still dealing with the with this uncertainty about you know rel while being an open open source operating system red enterprise linux was developed in a fairly proprietary way once it once it forked off of fedora we i mean the sources became available when we shipped them and uh you know we accept contributions into fedora but it was it was no clear pipeline for someone who wasn't a red hatter to get a patch through that entire system and i think now we have a much better story about that with eln and centOS stream so i guess that um leads me to another question what you kind of governance and decision making at the engineering level in eln so this is one of the things that i think is a clear distinction between the centOS stream thing and sent and fedora project which is if fedora in fedora although there are a lot of red headers involved if fedora makes the engineering decision our headlight um thing for that being the butter fs change right um those are those are made you know with input from red hat for some things but independently um and then centOS stream is set up basically you know as centOS linux was before all of the engineering decisions are for around the main centOS linux were made by red hat even though centOS branded red hat made the decisions and if centOS linux came out with something that wasn't like rel that was a bug like the decisions it wasn't supposed to deviate and centOS stream kind of follows that same thing the engineering decisions even though it's a community project the ultimate decisions you know come it's it's more of a we welcome your input and patches accepted kind of open source project whereas fedora is a you know you make the decision you see where i'm going here where does eln fit into that if i am somebody who is not a red header but very gets very involved like you mentioned there were non-red headers involved like can they ultimately how much voice do they have so i'm going to tell you the truth which may get me in trouble all right that's what that's what we like like which is that realistically and practically red hat cannot say no to what is coming what comes into centOS stream from fedora so if you have something somewhat controversial or just plain brand new fedora eln fedora and fedora eln are the place to push for that it may require it'll require you to work earlier in the process but it is effectively a way to bypass the bureaucracy inherent in trying to get your changes into centOS stream now i say bureaucracy and i know that carries a negative connotation but it's also very important for making sure that things get reviewed that nothing gets that nothing is being supported that is difficult or impossible to actually actually do so for i like in the centOS stream policy to and maybe this is a bad analogy these days but to choosing a supreme court justice for the US government centOS stream contributors nominate a change but it has but and red hat acts as the advice and consent for that change yeah let's let's not touch the third rail on going further on that analogy but i'm speaking nearly i don't know how it is it has been an interesting issue and it's actually something that that's actively being discussed right now on kernel because that's one place where people have been trying to get changes in particularly the hyperscale sig on on the centOS side is you know they've got code changes they wanted the the instance that kicked it off as they wanted some code updated from upstream and a driver that's turned off in rel right the config is turned off the sig would be building that module and supporting it but they wanted it in the real tree and their advantages and disadvantages to that um so there was some discussion about how do we take that how do we worry about you know do we have to worry about this chunk of code that doesn't interact and a decision really hasn't been made yet on what a firm policy would be but i i've heard uh you know a good bit of discussion around it's a lot of it's going to be up to the engineers uh discretion right if it's a dead code path or are they willing to take that and and maintain that stuff you know as obviously getting anything turned on you're or adding a package or something like that if it's if it's in rel it's supported so there has to be an engineer behind it that that supports it but even for you know for other things where you could you know i i'd like this code in there uh there might be a path it's it is being discussed it's just too new to to really have a policy yet i mean it's not it's not impossible that a controversial change made into infadora eln will be backed out when it gets to sent to a stream or but it is a lot more effort to do that than it is to get to uh figure out how to maintain it so still your your best bet is if you want to get something in that's uh maybe a little risky or a little controversial do it in fedora first i would say early how about early is the way to do it right i'm sure i think it's a way to it's a way to influence bigger changes and also have them proved and tested before they're actually hitting the rel level of yeah absolutely and i probably should have called that out but uh flip my mind um i've got a one or two more things is anybody else have questions i know there's other people still other people on the call here i'll throw another one out there um so what do you like how do you define success for eln and do you think you're achieving it right now i define success for eln as red hat continues to pay me and so i'm still working for red hat therefore i'm successful now um in all seriousness uh we will prove success when you know around the fedora 40 branch period where we will figure where we will know for certain as this all worked and can we basically jump straight from fedora 40 branch to developers can start working on rel you know give a give or take a week or two and rather than six months and i think uh with rel 9 uh we we had a great deal of success there i think we we took that six months down to something like seven weeks uh on that so yeah that's pretty good yeah that was that was a big win and i think we can do better uh for rel 10 i think we we're going to be working a lot on some automations this stuff that uh there's some additional automation that should make it a lot easier so i think that's how we'll define success is that we are essentially automating ourselves out of a job oh there's plenty of jobs for you don't worry uh so i guess um my final questions uh first one is yeah oh yeah you talked a little bit about what what the plans are coming ahead um what are the big things uh or are there big things that'll affect things from the fedora side uh or is it mostly you're going to implement on the roadmap of you know the rel 10 development and that's it or are there more big changes in store um i am i can only speak for myself in this case not specifically for the entire yellen sig but i am very strongly backing the uh the packet and source git horse and i think that uh we're going we're going to be we're going to want to see an awful lot more of that happening in the yellen space and that's going to and that and that will naturally filter to the into rawhide as well so that's there's a lot of potential there and i've been playing around with uh the packet source kit for some time now on just a few of my packages and i think there are still some rough edges but i'd like what i really want to get to is an is a point where a fedora contributor can take a patch from upstream slap it on it slap it uh commit it to a source git repository and everything after that is automated everything after that from you know from getting from building it in koji to preparing it for for a uh an errata update in bodhi to uh delivering it and to also to preparing it downstream for rel 10 or 11 uh all of that um i think should be essentially just it just happened once i come once the uh commit is pushed possibly some sort of human review of whether it works well a human the human review would have to take place before the push to source get it we would have to have ci and and and review that was very thorough so then there's the osci team is also very heavily uh involved the project i i think that's a i i'm excited to see that too so i'll be interesting to watch that it's the final question is uh what can we as the fedora council do to help eln succeed that's a good question um talking us up it never hurts lost your audio does that that's just you is it my herd okay yeah you're fine student maybe it's on my side okay um the question was uh what can the council do to help uh very much i think we helping us uh get our name out there let people help help us uh communicate what we're trying to do and especially uh i think one of the best things we can do we talked a little bit earlier about how sometimes there are maintainers in fedora that don't match the uh maintainers in rel and that they there is perhaps some friction uh around you know in those months leading up to rel that's the robolies i want to since we want to be trying to change that internally i think we also want to be uh making communicating that externally that to maintainers that uh you're probably if we do this right you are going to see more more contribution and more and more churn throughout the process and i think we need to work very hard on breaking that those ages old tendencies to think of the package as mine to remember that you are a steward not a shepherd if you will yeah um i guess i i i asked for what we could do so i will take that that part of it but i also want to um there's always a balance there between you know ownership and pride and that like the um there's a tragedy of the commons problem that can happen when when something doesn't you know when it belongs to everybody and then it belongs to nobody and nobody cares and so a lot of these packages where people have that mine feeling also means they've they're kind of invested in that and uh taking that away from people is um hard so there's a balance there to figure out and i don't actually know exactly how to strike that especially with this you don't have to have an answer to that that's why that's why i asked for door council to take it over yeah it's something something to work on so i guess that a general idea of you know shared shared responsibility for things um and uh maybe figuring out you know when when they're disagreements you know i know some people don't like to have any conditionals in their spec files like how to figure out how to take those kind of right that that was a that was actually uh thank you for bringing that up that was a topic that uh was very hot heated when the elans six were started um and in fact to date there have been almost 400 more emails about the topic than there have been actual conditionals added for spec files to to adapt to elan okay that's uh we we're well we're well prepared for if the situation arises we've already discussed it i mean well realistically people thought it was going to be much more intrusive than it was and i and uh did not initially believe our protestations that we were going to try and stay out of their way and i think our actions have spoken much louder than our words because i haven't heard a complaint about that in months that's good to hear that kind of goes back to what my first questions too um right is there anything else okay well thank you very much justin and steven uh ben this is the time of the call where i put you on the spot are you now yes this is the part of the call where i forgot that i should have the tab open ready to it's a little comedy routine we do because i do this every time and then every time i feel bad because ben is surprised uh what what's coming up next month april uh 14th we have leonardo rossetti and others talking about the cube dev sig okay that'll be interesting anything anything after that or are we looking for more uh there are items on the wish list nothing has been scheduled because we're not doing one in may because of the release party so and the one release okay so um if people are interested in uh wow june seems so far off but i guess it's not all right um there'll be we'll see you in the future i guess thank you again and goodbye everybody thanks