Hi everyone, so we're ready to start the next talk and I'm very happy to introduce Rachel who's talking to us about making fashion technology and Human organs. I'm Marissa Redd at the first time. I thought I was making it out of human organs, but it's not so anyway over to you Rachel. Thank you Hello everyone, sorry about the technical delay Okay, so today I decided to talk about what it's like making Well, as you guys are very familiar with the internet making and the age of the internet and To begin I'm just going to introduce myself I am my name is Rachel And I am known as Connie Chua Kitty, which is also the branding for my fashion tech I am a maker hacker Fashion tech engineer stem cell scientist as well as a mental health advocate So Why am I speaking today? I like to talk to you about Making wearables what are they and why I'm making wearables in terms of fashion technology? I also like to scare you or give you a view into the future of medicine using tissue engineering Which is the creation of human organs and Lastly just to share my experiences in doing both these things So first of all making wearable fashion technology The reason why I've designed this Presentation in a way that you know on how to get started is because I often get a lot of questions from people Asking how do you get into it? You know, especially since I'm actually doing something completely different, which is stem cell research So first of all, what is wearable technology wearable technology is a blanket term for electronics that can be worn on the body Either as an accessory or part of material used in clothing This means that it can be accessories that are specifically designed to fit on your body or Some sort of electronics attached to textile Which access a carrier for these electronics? So wearable tech can be categorized into two main categories namely health tech, which a lot of us know off and fashion technology So health tech products are such as fitness trackers Which helps you to keep track of your number of steps, how many steps you climb How many calories you burn your heart rate and also like it provides all your information and connected to the internet So you can find out more about it Fashion tech on the other hand includes clothing with expressions fashion tag doesn't believe in attaching a mobile phone or a Laptop to your body because at the end of the day, you're still gonna want to use your laptop You're still gonna want to use your phones for ease of accessibility fashion tech believes in creating a second skin in terms of enhancing and a user's experience So some examples of fashion tag includes Clothing that can reflect your mood or it can enhance your Experience if you are wearing it in a theater and it sends vibrations to your body I've selected Okay, well I've decided to try fashion tag rather than health tech in terms of wearables because I believe that fashion tag is a lot more relatable to a lot of people in the sense that With health tech you have to understand what the information provided to you mean So you actually need to put in effort to understand The information that's provided on the other hand with fashion tag Every day you have to make a conscious fashion decision You wake up in the morning and you think to yourself. Am I going to wear this t-shirt or that t-shirt? Will this trousers or skirt go with this top or not? So it relates to everyone So here I'm going to show an example of some of my personal fashion tag projects This is a floral necklace made with neopixel rings and controlled by the raspberry pie and the raspio hat Okay. Yeah. So The purpose of this is really just to express myself. Why should I wear a Basic chunky necklace when I can do something like this that not only express of myself But creates a lot of interest a lot of discussion And also encourages other people to try to do more with their accessories following that another project that I've made So this is one of the first Accessories that I've made it uses again a raspberry pi zero and a unicorn hat and The purpose of this is again to have fun to express myself and also this has encouraged a lot of People who like I I want to say girls or women But there are a lot of people other than girls or women specifically who like this kind of aesthetic And it encourages them to try electronics or basic programming So how to get started again a lot of people Asked how do I get started with making this when I show my pieces at exhibitions? So first of all the first thing that's really really important to get into making or Just learning a new skill is to be inspired So when I look for inspiration, you know I did a little bit of a google search and when I search wearables It just returned a bunch of FitBits VR headsets, which is not what I was looking for So I did a little bit more digging. I found a lot of images on Pinterest that attracted me for example this dress by cute circuit who Yeah, who displays various lights Cute circuit is a brand who has also designed clothing such as the twitter dress for people like Nicole Schoeninger Following that there is also this artist called Anu Weprak who designed this spider-like projections using servos and 3d printing to project when people invade her personal space, which I think is very useful At the same time fashion technology doesn't have to be electronics on textile or electronics somehow attached to your body It can also involve the type of technology used to design the material For example, LA's design create prosthetic covers using CNC milling laser etching and 3d printing So once you're inspired you're more likely to go and look into it even more So one of the things that I did which really helped me Know a bit more about electronics and coding is by attending events And at these events it helps to ask a lot of questions For example, I think there is a lot of you in this crowd who probably has an have an understanding of electronics coding programming and hacking I'm very new to this So a lot of times when I show up these events it helps me to ask questions like what is this Can you explain to me how this thing works and to use terminologies that I can later on Look up on the internet So some places that have been really useful for me to just learn a new skill is forums and chat rooms So the thing with forums and chat rooms is that it's helpful if you know what to look for If you know the right terminology in which my case I often don't know what to look for So I turn to social media With social media nowadays it's very easy to just take a photo of your problem Like if I build something as this white smoke coming out of it I'm just like white smoke you know searching on the internet but that's not helpful If I take an image of exactly the problem and upload it on Twitter I can get so many people to just help me just using hashtags like makers help or things like that If I can't find a specific person to help me people can share it They can retweet it they can tag someone else who might know better And lastly what really helped me was customer services There is a lot of customer services online such as platforms like Twitter For some reason these guys they don't sleep they have the person behind the Account is usually just a regular person, you know checking their Twitter all the time or they have it on their phone So when it beeps they can immediately answer your question again If they are not able to directly help you they would know of someone who's specialized to do so So another thing that was really helpful in learning a new skill is to try kits And you can there are so many kits out there that can be specified to so many different things There are kits that are specifically for basic electronics how to light an LED There are kits for soldering. There are kits for combining Cardboard craft with electronics and kits for programming. So here is an example of One of the kits that I've designed which involves soldering wires together because I realized that Most kits that teach soldering Is to teach you how to solder a flat something flat or like a flat PCB So through this kit To answer a lot of questions when people ask how do how can kits get started? How can they create accessories that Reflect the aesthetic. This is something that I created to show that On top of that, you know when you go when you buy something there's a If they have an online page There's a very good chance that they provide a lot of detail. Otherwise You can also probably find on youtube a lot of things and a lot of variations from what you've purchased And so go from there and that way you can create your own aesthetic So um moving on from that. I'm going to teach you how to make human organs So I am doing a phd uh that involves growing eyeballs using stem cells Um So people ask me how does that even work? So how to get started So what is tissue engineering tissue engineering is the use of a combination of cells engineering materials and methods and suitable Grow factors that help you create your ideal organ The aim of tissue engineering is to Create an organ that's personalized to you That will overcome any need for organ donors and overcome problems like organ rejection So how can we do this? So first of all, we need stem cells We would get these stem cells from patients who want to grow their own organs Secondly, we need scuffles What are scuffles? Scuffles is basically the house that the cells can attach to in order for it to grow Other things that will be needed is growth factors. So they're basically food for these cells to survive Vasculature provides A network for delivering this food What's really important as well is published and unpublished literature And the reason for this is because Research is a race against time If you create something that hasn't been published You want to put it out as fast as possible And when someone has published that And if you are working on the same thing You want to use that as your stepping stone to push you ahead of that person so that you can publish the next thing Unpublished literature refers to things like collaborations Lastly the goal of tissue engineering again is to create off-the-shelf organs So that one day you'll be able to go into a shop and be like You know pick and mix. I want a little bit of this I want a little bit of that and I like to put all of that in my liver because I'm a heavy drinker that sort of thing So To give you an idea what are stem cells? So stem cells can come from Any part of the body Stem cells are basically the baby cells That create an embryo So in the early days stem cells were harvested from embryos Right now we can obtain Stem cells from just a simple skin biopsy of a patient So this is very non-invasive Using a simple skin biopsy We then give it a lot of growth factors to make it think that it is in an embryonic environment When it thinks it's in that environment, they then go back against time and reverse their age So from a mature brain cell a mature lung cell a mature heart cell They go back against time and become an embryonic stem cell So using this embryonic stem cell When we study human development, we're able to target what sort of growth factors cause it to develop into a brain or heart a lung We use those same growth factors apply it to these embryonic stem cells And we have our organ But it really isn't that simple because if you grow a mass of cells, it's probably going to form a tumor It's not going to form the shape that you want it to So this is where we introduce scaffolds So this is an image of a decelerarized liver and a decelerarized large intestine So decelerarization is the process of using various detergent and enzymes to strip an organ of its cells and DNA Once you strip it of all its cells and DNA it loses the natural pigments that you normally see And give you this transparent structure This transparent structure acts just like a scaffolding of a house When you're building a house you're going to need scaffolding to hold things up So this scaffolding Which is the Yeah, the the structure of the house When you add cells to it, it's like adding bricks to a house These cells will then specialize into different things like A living room in a house for example, and that would be a specialized heart or brain And so on So moving on to things like Psyhub, what is it? So there is a lot of people out there who are not you know subscribed to various journals and also A lot of these journals are only accessible to people who are in academia And I don't think that should be the case You know like nowadays It's so easy for us to find information, but we do want to be well informed and not just Reading off some news, which is not properly cited or reference So Psyhub is a place where people go to get these journals free So there is so there's a couple of issues with this website, you know Legal issues and things like that, but various more have popped up So if you want to be well informed just look up a very good journal a very good review And from that a good review will teach you everything from scratch You don't have to be an expert in order to get started So that's It for you guys if you want to go home and create your own organs all you need is a scaffold Some of your own stem cells just a simple skin biopsy And then you're basically ready to go you also need a bit of some financial help, but yeah Figure that out So just to sum everything together I like to talk about the obstacles and lessons I've learned through making So How many of you have heard this phrase? There are no more original ideas It's been said so many times and I've heard it more and more recently just because You know the internet is so accessible. It's so easy to find Something that you've made that looks similar to something someone else has made Does that actually Make your idea unoriginal? I don't believe so because ideas stem from problems It is We are a lot more related than we think we have a lot of the same problems If you have the same problems, you're probably going to come up with the same ideas Again, that doesn't mean that your idea is unoriginal No one's going to say hey, you copied my problem so Your ideas are yours your ideas can be similar to someone else, but they are original But if you do Look up, you know, like how to solve a problem And then if that thing inspired you to create something of yours It is important very very important to credit where credit is due So one of the first things you can do when you want to credit someone is to ask Ask how they would like to be credited Because some people they don't like to be credited. They're just like, okay You know, I just put this up and I just want to stay anonymous. So that's really important And more importantly, you should ask whether it's okay to use whatever it is or to share whatever it is that you want to share That belongs to someone else Secondly Inform them where you're going to use it just because you know, just because you credit someone It's not okay for that person to turn up somewhere and realize that they are, you know The information is just everywhere and they don't know where it's been said. So that's really important Secondly I think it's really really important to say thanks you know, because when you do In cut when you do say thanks to someone for their idea It really encourages them To do some more to want to contribute some more to the information that is already readily available Lastly when you say thank you to you know, someone who perhaps created something they are selling it, but it inspired you to go and make your own Do say thanks because it encourages And promotes small businesses which With again with the age of internet can really struggle because it's so easy to go and make your own thing rather to purchase Something an artist has made So I get this question a lot. So I like to address it a lot of people ask me, you know, I do stem cell research Why am I doing fashion technology at the same time? It's completely different, you know growing eyeballs and necks blinding people with lots of lights So I do this because I'm trying to live the best life that I can And I say this because This used to be my life You know, there I think a lot of you here you love your work and Like me, I feel very thankful to be doing something that is work, but I am passionate about But the thing is that For a lot of us Well myself specifically speaking from experience I loved it so much that I didn't think I need anything else I was like, you know, like this I'm doing life changing research Like none no either of my needs actually matter And when you're so passionate about something it's very very easy to neglect all your other needs So I Suffered from burnout over something that I love I also had severe anxiety and depression and I had no idea where they came from So being there a scientist that I am I did quite a bit of research into mental health Which is also work by the way And then I found out that Life requires balance, you know, you think you might not need it, but it makes life So much more colorful I after a full day of work I go home and I'm like, oh my god. I have this idea.  You know, I have a really long day No, I'm going home. I'm skipping home. I'm like, yes, you know, I have this idea I want to make it real And this is why I've incorporated making into my life and why I think it's very important and I think that brings me to the end of my talk. Thank you very much Oh, yeah, sure. Uh, does anyone want to ask any questions? Yeah, I can repeat that How far have you got in making the eyeballs? We are actually making them right now In terms of growing eyeballs, it's quite special because they are They don't require a scaffold If you grow them in an in the right environment It forms its own optic viscicles so From a mess of cells it starts to Invaginate and form a little ball So eyes are pretty special. We are already there. We're just Trying to make sure that the cells we're working with are functional Any more questions? Um, great talk by the way. Thank you. Um, I was just wondering I think I saw that you sell kits online. Yes How easy is it to run a business as well as doing your making and your phc work and is it Is it worthwhile as it's sustainable and and is yeah, what's what's that kind of side of it like? Okay Yes, I am So as I said earlier, I'm selling those kits Which helps you create is this light up? It's meant to light up, but uh, it helps you create one of these little cat ears Yes, I do run a business. It is tough because It's just me So I am the marketing the packaging the posting the Everything the design and all that is just me um It can be difficult but With everything being online. It's a lot easier. You don't have to have a proper shop You know when orders come in you can just say that everything's going out on this specific day And people are willing to wait for your product if it's something that they really want Um, and just so you know, there is a cyberpunk marketplace later on in the evening And I will also have a shop there. So if you guys would like to check it out. Yeah Uh, any more questions? Um, how closely to actually implanting the eyeballs in people Um, it's actually happening right now a lot of the research with tissue engineering Um, a lot of times it is happening to patients who are in extreme circumstances So it is a trial, but it has been very successful. So for my masters, uh, my lab and I created a Tissue engineer oisophagus, which is the track that allows you to um, take food And it has been published. Um, and the follow-up of the patient is very successful And this patient is a child So we were amazed to see that the transplanted organ was growing with the child All right, uh, this question Do you think there'll be a point in the future where your hobby crosses over with your career and you kind of have like technology Incorporated into the organs um, it is I do get that question a lot and I don't really want them to cross Like it is sort of the main reason why I'm doing two very different things Um, yeah, I do get that question a lot and there's a possibility that um The fashion tech side of things might actually grow bigger and that might become part of my career And so I will have to find a way to build my own lab to grow my own organs, I guess Okay, so, uh, should the problem why our organ is being replaced if it's genetic Wouldn't the replacement organ also be prone to the same problem? Um, the answer is no, uh, so so as we know the problem with um, organ donors is not only because there is it's very limited Um, there's very there's a very long queue for organ donors, you know, and it's also very limited in the sense that you have to match your DNA So the the reason why we are engineering organs in the lab is because When you strip an organ like so we can use scaffolds from animal organs or an organ that is no longer fresh freshly harvested from a cadaver um These organs are stripped off its cells and DNA So the remaining extracellular matrix Is just a matrix that has no, um properties that will cause organ rejection So when we see these these extracellular matrix with the patient's own cells, we are essentially growing the patient's own organ Yeah, that's what I meant like, uh, if the patient is predisposed genetically to a disorder Would that same disorder be in the like grown organ? Yeah, so this is where gene editing comes in. So one of the things that I do in my lab is gene editing because we have um, so I have patients with congenital blindness So in order for us to address this issue and to grow their own eyes We have to firstly correct it by using a CRISPR-Cas9, which is a gene editing tool And through that we try to correct that um that gene that is producing the wrong thing And through that once it's corrected, we again have to test whether the cells work functionally Whether the eye cells can detect light and then before transplanting and yeah Any more questions I want to sit down so people can't see Um, obviously you talked you talked earlier about picamix And just now with gene engineering. So how do you address the morality of custom-building organs? And potentially people being able to custom-build characteristics that they particularly want within their stem cell organs Hello, hello, there we go Hi, sorry about the technical issue So in terms of picamix we would ideally like to change certain things depending on the lifestyle of the patient So, uh, and we would change that in terms of growth factors. So we will actually have to study It better in terms of human development I hope that answers the question We can speak more Thank you everyone


Hello and welcome to this very short talk that is provided by Kurt Galloff and me, Marius Feldman. Doing this talk that is titled Digital Serenity Why Open Infrastructure Matters, we would like to shed some light on the term digital serenity, which is currently intensively discussed in IT industry in Europe. And on the other hand, we would like to interlink the goal of digital serenity with open infrastructure projects. But before we do this, let's have a clear differentiation of terms. And while we want to use this differentiation to clearly point out that digital serenity is not about digital autarchy. Sometimes these terms are confused and are mixed up. However, it's very important to differentiate this. So it's not about building up a wall, for example, around Europe, and to keep all the nice interesting ideas, nice concepts, and specifically also existing nice technology outside of Europe, and do everything on our own here. But it's about integrating these things into an overall ecosystem. So digital serenity, then in the end, is integrating these things, but adding also own solutions, for example, in order to have really the freedom of choice among different options that exist. The core question here is, if while digital serenity means having the freedom of choice, what are essential preconditions to achieve this? Preconditions obviously are there should be alternatives available. Well, actually, if you do not have alternatives, you have no freedom of choice. That's quite obvious. Apart from this, the alternatives really have to differ, which means while they have some functional and non functional properties that are different. So that differ from each other. And apart from this, this is the last aspect that is absolutely fundamental. We need some means and possibilities to discover the digital services that are offered based on the properties to give a simple example. Well, for example, somebody offers a super secure digital service or a very sustainable economically, as well as ecologically or sustainable service, then it should be possible to discover it for sure. So these aspects, among others, have gained momentum in Europe and are currently intensively discussed. Specifically, they are also discussed in an overall interesting project scope, which is named GaiaX. GaiaX is a project that has been initiated by the German Ministry for Economy and Energy back in 2019. And currently, hundreds of companies, not only European ones, but companies from all around the world, work actually on that project in order to push forward the overall vision of digital serenity. In the next step, I would like to give a short insight, a very short overview of this GaiaX project. In order to do so, I've taken this image from the so-called Technical Architecture Documents that has been published in June 2020 by the German Ministry for Economy and Energy. On this image, you'll find the broad spectrum that GaiaX covers. So on one hand, the goal is to establish a data ecosystem, and on the other hand, infrastructure ecosystem. Both of these ecosystems should be heavily interlinked and centered around different technical and non-technical solutions that fall to different categories, such as identity and trust, sovereign data exchange, compliance, as well as a so-called federated catalog. If you would like to get any details on that, I recommend to read the Technical Architecture document. However, we want to focus very briefly on this federated catalog. So this catalog is exactly one of the solutions in order to achieve digital sovereignty as this federated catalog intends to hold so-called self-descriptions. So self-descriptions are descriptions of functional and non-functional properties apart from other aspects that are provided, for example, for digital services or for data, and that are published via this federated catalog. And then users have the possibility to search for services, for example, via this federated catalog and consume them in the next step. So as I've mentioned, this is one of the core components that address the digital sovereignty in regards to the definitions that we have discussed beforehand. So with this, I want to leave the GAIAX project behind with, well, one central aspect that I still want to point out. And this is a quote from page 25 that you find in this Technical Architecture document. The quote is, a strong open infrastructure ecosystem is a foundation of digital sovereignty. The interesting part is that there's absolutely no explanation for this statement within the Technical Architecture document. So, well, it's on the reader's side to give an interpretation. And this is exactly what we will do during the next minutes. However, before we start to really inter-relate open infrastructure and digital sovereignty, let's have a brief look at the current situation and the overall future situation that we predict. So here on this slide, you see on top a single cloud provider. So we are over-exaggerating a little bit the current situation. You see a single cloud provider that is operating a set of services. And this single cloud provider has some specific on provider properties. So some characteristics such as, well, it's energy efficiency, if this cloud provider is GDPR compliant or if it is not GDPR compliant and all such things. Actually, these properties are the foundation for several such properties also on the service level, which means that these properties are partially or completely reflected on the service level as well. Which means in the end, if you only have one cloud provider, well, then there is also no diversity on the service side in regards to these properties. This can be only achieved if you have several cloud providers and have several, well, private or also public infrastructure providers underneath these services having different urban properties in place. So this means that these provider properties, as we have just called them here, have a huge impact on the properties that the services that are offered have got. So specifically, for example, centered around GDPR compliance, energy efficiency or the used hardware, maybe to add some additional things, for example, also specific security means or something like this, this that a specific provider has in place, these things are then reflected on the service level. What does it mean? Well, this means if we do not have several providers, if we do not have a decentralized setup where there exists different providers, well, then we will not have digital sovereignty based on what we have discussed before. Actually, we have mentioned that in order to achieve digital sovereignty, meaning to have the freedom of choice, you need alternatives that really differ. So if there is not a specific threshold reached in regards to how we think differ, well, then there is no digital sovereignty in place. And this as a consequence means we need also heterogeneous decentralized infrastructures where the providers, the private infrastructures have properties in place that really make a difference. So only then you have really a freedom of choice, thus you have then only an option for digital sovereignty. This means we can formulate a thesis here. Future digital infrastructures are not monolithic and centralized, but highly distributed and heterogeneous regarding their properties. And this exactly based on the definition that we have provided before forms the fundament in order to achieve digital sovereignty. So on this slide you see how this may look like. So for example, here we assume a highly synergetic digital infrastructure that consists of several digital infrastructure units of different sites that are in a synergetic relation to their environments, more specifically to assets that are available already. So for example, it may be that there's a district heating system, it may be that there are renewable energy sites and the digital infrastructure units, they are in synergy with these existing assets. And on top of these digital infrastructure units, then a cloud infrastructure is for example operated, that is leveraged. And these different sites then have quite unique characteristics in this specific example, for example, in regards to their energy efficiency. This may look like the pictures that you see here, so just some sketches to point out how this may be materialized. For example, well, the digital infrastructure unit directly next door to a wind park or to a solar farm in order to well then have cheap and renewable energy available in order to operate these digital infrastructure units. To sum up, this means that we are thinking digital infrastructures of the future as decentralized infrastructures with several sites where there are also several providers behind this that operate these infrastructures. And for sure all of them will have their own solutions in the first place for setting up this infrastructure and for operating this infrastructure. So where's the downside of this perspective? So we can identify two general drawbacks here. First of all, the first drawback is related to the APIs. So it may be for sure that each of these providers offers different APIs in future. So if we have, for example, as here, three different providers, then we have three different APIs that are handed over to those that want to run services on top. And again, we end up in a vendor login situation. So the situation has not improved at all. The other aspect is related to the platform that is used. So it may be that while each of these providers leverages a different platform, even if these platforms that are used in order to operate this cloud infrastructure or digital infrastructure may be based on an open infrastructure project, this may still be an issue as, for example, this open infrastructure project may be adapted or changed a little bit. So that again, it's a sort of own solution. And this is the reason why I have mentioned in order to over-exaggerate things a little bit on that slide, that these providers have a proprietary cloud platform in place. So in the end, what we can see here is that having this future perspective means also, if we do not, well, change anything, that we have three times the development effort for creating an operational system, even if it's based on an open infrastructure project or a set of projects. Plus we also have, as we have just discussed with regards to the API, a vendor login situation. So in order to solve this issue, we could just easily claim that there should be a standardized API for all of these providers on one hand. And on the other hand, we should just request a single platform that should be used or demand a single platform that is used in order to operate the different provider infrastructures. Well, this sounds like a slight contradiction, right? On one hand, we are saying that future digital infrastructures should be heterogeneous in order to really have alternatives available due to the different properties. And on the other hand, we are requesting standards, standards for the API as well as for the platform itself. So does it make sense? Well, actually, we should not mix up things. We should really take care about what we are talking. And when talking about standardizing things, we are actually talking about a specific layer. This specific layer is providing virtual machines, virtual block devices, virtual networks and all these things. But in the end, this layer is providing commodity. And actually, it does not make sense to have many alternatives on this layer. Thus, well, standardizing things pretty much makes sense to really demonstrate this with reference to the image that we have used before. So here in this image, you see this commodity layer visualized between the services and the infrastructure itself. And if we have a look at the provider properties or infrastructure properties again that affect as well the service properties, as explained before, well, the commodity layer doesn't make any difference in regard to these properties. So for example, if you have a very energy efficient provider, or if you have a provider that leverages specific hardware, or if you have a provider that is located in a specific country, all these things are directly reflected on the service layer without any impact from the commodity layer. For sure, this is a slight simplification. So it may be that some specific adaptations to this commodity layer may be made that then have definitely an impact on the properties on the service layer. However, in general, this commodity layer should have as little impact on the properties as possible. And due to this, this commodity layer is a perfect area, a perfect field in order to have generic projects in place that solve actually the technical issues on this layer. So in the end, the commodity layer should leverage open infrastructure projects to render possible possible collaborative development and to avoid API fragmentation. So to sum that up, we can point out that open infrastructure is bridging the chasm on the commodity layer. Thus, well, the wheel should not be reinvented actually. And to point out the core findings now, well, on the path towards digital serenity is absolutely crucial to provide a modular open infrastructure solution that renders it possible to enable various actors to set up an operational platform for hosting services quickly on one hand. And on the other hand, open infrastructure projects should reduce development overhead and should ensure API interoperability in order to avoid specifically vendor login, which would contradict the freedom of choice. With this short summary of the first part of the talk, I would like to hand over to Kurt Galloff, who now will introduce a very concrete project, the so-called sovereign cloud stack, that materializes actually these findings that we have just pointed out. Thanks, Marius. My name's Kurt Galloff, and I'm going to share a bit of information on the sovereign cloud stack. So what is it sovereign cloud stack is a project in GaiaX, and it provides what Marius just referred to as the commodity layer. So we are all about providing infrastructure software to ensure their sovereign infrastructure in GaiaX. We provide a complete open source cloud software stack. When I say open, we really subscribe to the four opens of the open infrastructure community. We do provide a lot of infrastructure software, such as virtualization of storage using SEV, virtualization of networking, compute virtualization, obviously, based on open source technology. We have significant amount of operations tooling, tools for doing CI, for automating deployments, for automating updates, monitoring. On top, we put an infrastructure as a service layer using open stack for that. We have a Kubernetes as a service layer on top of that. And when I say Kubernetes as a service, I do that on purpose. It's not just containers as a service, but we do provide customers the ability to provision themselves via an API, a standard interface, Kubernetes cluster, and then control the lifecycle of that. We have some tooling around the containers, which you expect in the container space, as well as identity and access management solution in place that allows you to federate with other clouds of similar nature. The stack is complete, but it's also modular. That means if you're an existing provider and you don't want to use the complete full SCS stack, but want to stay on tools that you already have deployed on pieces that you already have, you can do so and only consume some of the SCS modules. To make sure that we deliver on interoperability, that we really are compatible at this commodity layer, we do have strong standards, so stronger than what you are used to see from the open stack community. We really want to make sure that if you're using several SCS-based clouds, you will have no trouble at all to move applications from one to the other or to use several at the same time and not even notice the difference. Those standards really do not end at the API layer, but we really want to define also the behavior and also certain aspects of how those clouds are being operated. Those standards are being certifiable, so you can actually prove as a provider to your customers that you adhere to those standards. We have federation built in by design and compatibility that just talked about is just one aspect of that. Identity federation is an important one because you don't want to manage your users and the access rights that go along with that on each cloud separately. You want to be able to do it once and then define this for all of your clouds that you're using. Of course, you do need a network connectivity between those clouds. You want to have the ability to create secure tunnels or secure connections with the bandwidths and latency requirements that you have. Finally, we're spending a significant effort to actually work with the operators, support them, to really build an ecosystem out of them. We want to make sure that we extend the idea of working together according to the four opens in building software, also in sharing operational knowledge and really make sure that providers open up and learn from each other and don't need to solve those same hard and difficult problems that you really see in day-to-day operations independently of them. We really want to make sure there's a network of providers also working together at this base commodity layer that Marius was talking about. This helps to improve the quality and also to make the quality more transparent to users. This is a slightly different picture than Marius showed that gives you an idea how the GAIA-X ecosystem is being looked at. At the bottom layer you see the infrastructure ecosystem and this is where the sovereign cloud stack provides an option for providers to have sovereign infrastructure. Talking about where we are with our project, it's a really young project. We only started somewhat less than a year ago when we first came together and had this idea. It was initially initiated by a group of members of the open source business alliance. This is an alliance of German speaking countries, open source companies that really work together there to kind of define their common interest. We have built a very small team based on this idea and that team really consisting out of a handful of people is now coordinating and orchestrating a much larger community of contributors, contributors for companies where IT departments work with us because they're interested but also existing and new cloud providers that are interested and contributing to this effort. We have been lucky to receive some funding from the agency for disruptive innovation in Germany for this year and we're also currently working towards a larger funding proposal that we are trying to get funding for the next years and I'm very optimistic this works out. Very importantly we have a significant number of companies and partners that are supporting us not just from the open source business alliance but also various companies from the industry as well as cloud providers. We have companies from Sweden and France that have joined us and are supporting us. We do have a trademark, we have a logo, we have a web page, we have open source code available on github. We're part of the GaiaX community. We're also working with supporting the foundation that's being built up in the GaiaX ecosystem and SCS is established as an official word package in GaiaX. We do talk a lot to people in the industry but we also received some very positive feedback from actually companies that support IT in the public sector and we've also recently had quite a bit of coverage from press mostly in Germany and I have to say that was really motivating and positive because people seem to have the impression that what we are doing is really something that needs to be done so we are happy to be there. On the technical side we have worked quite a bit on already providing technology so we have code out there and that code can be used already so we can do deployments fully automated with the available code so we have been successful integrating all these existing open source projects in an automated way, validating them and making them available. We can do bare metal installations, obviously there's a few steps in the bare metal installation that are not fully automated because you need to do the cabling and put those machines in the rack but once you've done all that you can actually do it fully automatically but also very nice for testing, for validation, also for demos is that we can actually deploy on top of an existing infrastructure as a service solution using Terraform so we can actually put the server cloud stack which includes OpenStack on top of an existing OpenStack deployment and that takes between one hour or maybe 90 minutes depends a bit on the network connection and performance of your environment. That is very useful, we have that running at more than half a dozen cloud providers, we also have to where we actually have already physical installations. Finally the container layer, the Kubernetes layer is something we're currently still working on, we're struggling a bit with it to be very honest because the Kubernetes cluster API does not seem to have adopted and mature as much as we would like and this is kind of preventing us from coming up with a final standardized solution in that space so we're working with the SAP Gardener folks, with the Kubernetes folks, with Rancher, we have been talking to Giant Swarm to see that we can work together but we still need to kind of define this common standard to really get a breakthrough in that area. This is a short look at the architecture which I will basically skip to avoid running out of time. That being said, let me summarize, Mars I think has very well explained that serenity is important that it matters. In order to achieve it you need to have choice, you need to have control so we need to make sure we have a diverse decentralized ecosystem for providing open cloud infrastructure. Right now we have somewhat of a fragmentation that really is not helpful if solutions that are open are incompatible to each other that does not help and the second observation we have is that it's very hard to provide a high quality operations of cloud infrastructure so SCS is trying to help this with standardizing making sure we make the operations a lot easier and with also making sure that all these infrastructures that are based on SCS are compatible to each other. That's it, I want to invite you to join the two SCS sessions that we have today, there's one at a quarter past noon and there's one on Wednesday morning 9.15 a central European time. I have provided three links to that you can go to to get further information and I would be happy if you join our team and supporters developing this project. Thanks for your attention, if you have any questions to Mars or myself please ask.


Hello, folks. Welcome to day three of the CoreOS virtual face-to-face. This session is making Fedora, CoreOS an official edition. I'll set some ground rules and then pass it off to Clement, who will lead the discussion. This is a virtual face-to-face, so if you feel comfortable, please turn your camera on so we can see your beautiful faces. Please use the raise hand ability of Google Meet to queue up your question or your response. And finally, because there are a number of faces here from Red Hat and elsewhere, please provide a short introduction. If you speak for the first time, that would be very helpful. Without further ado, Clement, take it away. Thank you, Micah. I'll start by introducing myself. I'm Clement Verna. I'm currently a manager with the CoreOS team. I've been contributing to Fedora for, I don't know, four or five years now. And I'm the owner of the change proposal to actually make Fedora CoreOS an official edition. So a bit of background. So during the Fedora 34 change cycle, we proposed to actually promote Fedora CoreOS as an edition. And we received some quite good feedbacks. This session is pretty much the opportunity to go together through those feedbacks and try to see how we address them and how we can improve our change proposal. And pretty much see the way forward with it. In the ICMD that has been shared in the documents, I tried to summarize some of the feedback and also some of the key concepts that I think we care about. And I would like this session to be very open discussion and kind of like almost brainstorming. So I don't intend to do all the talking, even though it's hard for me sometimes to listen. So yeah, feel free to participate and to share your opinions. Every opinion is welcome. We are all respectful of everyone's opinion and everyone is valued. So please participate. So some of the key concepts that I think we really care about. And probably the main one that caused a bit of discussion is that I think we care that we don't really want to be a Fedora CoreOS 33 or Fedora CoreOS 34. Fedora CoreOS is as its own really cycle and we have like those concepts of streams with our next testing and stable stream. And for the end user, really the base of Fedora CoreOS on which base of Fedora version is based Fedora CoreOS shouldn't really matter. Ideally I think in the change proposal, I think we want to adapt to the Fedora process and how we integrate and we interact with the wider community. But I don't think we want to be tight and we want to be restricted by like really fitting within these like six months releases and having like Fedora CoreOS 34 release announcement or things like that. Do we have an agreement there or is it like something that I've pretty much is something that I thought was like something key, but I might be wrong. So is it something that we feel we pretty much aligned on no objection. I have no objection. I have two comments. One is this is one of the things I talked about like I proposed at like the flock in Prague like seven years ago or something so I'm glad to see that we're finally at the point where we can actually tackle doing it. So you know, slow progress towards the future. We eventually get good places. One thing I think that needs to be worked out with that is how the we don't have releases works with the release blocker progress process because release blockers are one of the few big hammers we have for serious bugs in all of Fedora. And so if if you know generally one of the things we've said around additions are those are the ones where we take blockers most seriously and that's one of the important things about being an addition. If this addition isn't on the cadence. What do we do with blockers there do we if there's a blocker in Fedora CoreOS do we not ship the other things until it's fixed. Or do we say okay we're just not going to rebase onto that new underlying thing until then I don't I don't know the answers but we need an answer to it. Yeah, that was I had one point on that. So I think we can we can dig into deeper into that Benjamin you want you wanted to to comment on that. Yeah, up to this point anyway that's been part of the reason that we have tended to ship the stable release the rebase the stable release a little bit later than the other Fedora additions. So you know there's a bit of a chicken and egg question but what we generally do if we find some last minute blocker for Fedora CoreOS is we'll just hold stable. That may not be the desirable outcome in all cases I think it's useful to have some access to that lever to get packages fixed in Fedora as a whole. But it's also not strictly necessary like if there's some blocker that only affects the Fedora CoreOS addition and not the others. It may not be the right thing to hold everybody else. I'm in favor of that we just may need to develop some new levers that's the other topic that is going on this is publicity because it tends to be that journalists expect us to tell them what's going on in Fedora in our release announcements. We can still do that, but that dilutes the message of there's not there's one stream and not different releases of it because people are still going to secretly think of it as Fedora CoreOS 34 if we emphasize it in the release announcements all the time. So, again, I don't we don't need to delve into that topic right now but we need to figure out a way to do publicity in a separate way. I think next person that was Ben, I think you always do. Hi, I'm Ben Cotton, the Fedora program manager. I want to build on what Matthew said a little bit and in terms of holding the stable release a little bit behind the main Fedora Linux release. I think that also presents a problem when people, you know, on release day, go to try Fedora CoreOS and they're like, wait, why is everything the older versions of stuff. And, you know, the addition, the addition process is as much a, for lack of a better word, political determination as it is a technical one. And so, you know, that's where a lot of these process misalignments are coming to a head where they weren't an issue before. Corina, you want to go next? Yeah, I think there's a lot of like interesting potential technical process. To me, this feels more like an intent, like we will solve these things over time. Like, it's not that we have all the answers right now, but just that, yeah, we believe we can address those sort of things and sort of intend to do it. Because, you know, this tension actually comes up in other cases. Like, I saw Ubuntu actually very recently switched to doing stage rollouts for apt 2 because, you know, like they see the benefit, right? And so, like, you get these sort of like crossovers. So, like, Ubuntu recently, it basically has that same problem. But, like, if you type app update on one system, I mean, I do the same thing as another, right? And, yeah, it's just, it's part of this switching to this world, right? And Simone Tau? So, one thing from the keyway side of things that Matthew already mentioned, we have something called a blocker bug meeting where we kind of discuss, you know, whatever it is. Whatever the blockers are. And then, you know, just before every Monday. Now, technically, we file and maintain all those blocker bug review process as synchronously on a blocker review app that we maintain. But, most of the cool stuff are filed on GitHub. So, there is not much. How do I put? There's not much link between what's there on GitHub, should we replicate those on Pugger and is it possible by which we can have those, you know, kind of cater to while we do the release blocker meeting, rather than having them come at a very late time and then be like, oh, yeah, this was not discussed before. Yeah, I think it's. So I guess to try to summarize and we pretty much have to, like, my feeling is that we have to come up with, like, our own process, but also in some places, like, for example, the blocker bugs. Also, in all, like, the publicity and marketing, like, see how we integrate with other teams within the community and, like, having those bi-weekly releases. How does, how do we, how are we doing that? So, I had, like, my first point was on, like, development and how we integrate with the federal change proposal process. But I had, like, the go-no-go process and release blocker as a second point. Since we started on the subject, maybe we can go into that topic a little bit more. Benjamin, you wanted to. Yeah, just to provide a little bit of context. Oh, I did introduce myself. Benjamin Gilbert. I've, I was very heavily involved in Fedora CoreOS in the early days. I'm less so now when I'm still around working on Ignition and Chorus and so on and things. The reason I think that we're so hesitant to commit to rebasing Stable at any given point is that we have the additional burden of, like, of automatic updates. Fedora CoreOS in particular, so this is just for context for anyone who doesn't know. Fedora CoreOS in particular, we try very hard to never have users have to go manually fix up something. The machine automatically updates. It's sort of an appliance. You don't have to think about it. And if we push out an update that breaks somebody, the concern is that that motivates users to turn off automatic updates and they're not getting their security fixes. So a lot of the decisions around the stream architecture and some of the things we're doing differently are driven by that goal. I think we're much more conservative in terms of updates and what changes also in the OS compared to maybe over-edition like workstation. All right, on the... That's good to let people know because that helps people's confidence in the whole thing. I think this can be a selling point that this is actively managed. Timothy? Hi, so I'm Timothy. I work on the CoreOS team. I think this is linked to the way we do changes because the major difference between Fedora CoreOS and Classic Fedora is that we push changes on a regular basis and we don't go through the same process of having changes be prepared and submitted for review for each release because we don't block them on being in a specific release. So in a way that the release currency is also linked to the fact that we do changes differently and that's something we have to reconcile somehow with the way Fedora does... Classic, I would say Fedora does changes. Yeah, I'm looking at you, Ben. Cotton. I have no answers for that easily. All right. A lot of it is that Fedora CoreOS happens sort of independently of what we typically think of as Fedora and it's partly a question of how much do we want to change that versus how much do we want to keep lending the Fedora name to Fedora CoreOS and have it continue to be essentially an independent tangentially related project. Yeah, I would like to see it. I think having changed proposals going in and mostly they will be self-contained proposals so they don't really need anything. It's not like we're adding another level of approval that needs to happen to these but they go through and people see that this is a thing that's going on in mainstream Fedora activity. I think that'll be pretty valuable and it also helps build the community referencing back to last call. So I think it's a good thing to do that. Maybe we just need a way to tag them as something other than tied to a release. Just call them Fedora CoreOS changes or I don't know, yeah, Ben doesn't like that but let's see that's why I'm looking at you for answers here. Yeah, to be clear the only reason I don't like it is because it very much changes everything we currently have. Not necessarily that it's the wrong thing, it's just a lot of work to re-engineer processes to handle a new paradigm. Jeff? So I'll try and throw this out there. I have people who I recognize upstream would like to replace Docker with Podman, for instance and have no Docker shift on Fedora CoreOS. Is that something that I suggest to Fedora in general? Is that something I suggest just to the CoreOS folks? Is that something that only happens on GitHub? What would be the process for doing something equivalent to a Fedora change request in Fedora but specifically just targeted at CoreOS? Yeah, this hammers on what we were just asking, Ben. So my instinct for that is that is a great thing that would be a self-contained change. If Workstation were saying we're going to do the same thing, we would ask them to do that as a self-contained change and it's a self-contained change because we're not saying we're going to drop Moby or whatever from the repositories. That would be a big deal. But if we're saying this addition is going to ship with Podman instead, that's something that would be a self-contained change and it would be mostly for the stakeholders of that addition to discuss and then for that to be a publicity because users need to be aware. So I think that's probably the right thing to funnel it through whatever it is. And I think having it look like the existing process is... I think having it part of being part of the existing process is desirable. I don't know if anybody disagrees with me on that. I'd like to hear it. One thing we discussed yesterday on documentation and was also to try to... And I think the state discussed it also, having better release notes and things like that. So I see value in taking part of the change proposal process into the terms where it gives us some content to talk about and say, oh yeah, look at what changed in the last month or the last release also. It's just really how we adapt the fast pace of Fedora-Caro is to... And those things get picked up by Linux Weekly News and Pharaonix and occasionally bigger journalists as well. So it does help publicize things. Gordon? Yeah, a different meaning brought up with you. It's actually a really good example of something that probably should have been a change. We just wrote a new software from scratch to update the boot loader. It doesn't affect other editions yet. It is intended to also support young-based systems or even deaf-based systems too, eventually. Because the traditional package managers just aren't very good at updating boot loaders. So one thing I've been thinking about is we could try and align the six-month change cycle for some of these things. But the other thing that's a real tension is we wrote this because we wanted to ship it in OpenShift too quickly. In some cases, waiting six months for something to land can be a real problem and others may not. And I don't just don't know how to... I mean, I don't know. This gives you a whole big discussion. But actually, the Rust compiler is a six-week cycle with longer epicycles. But anyways, I'm just bringing that up. I just feel like it is a really good example of... Yeah, boot up is just a really good example of how we track this change, I guess. Benjamin? I think there's value in not stacking up large changes and landing them all at the same time around a rebase. Just from a change management perspective, that way we have fewer fires to fight at any given time. So we could actually plan or know that we have a few changes coming up, but plan those changes for different stream releases. Ben, you wanted to... I just wanted to clarify one thing about the six-month process. So the window between the self-contained change proposal deadline and the GA release is about three months. So it's not like you would put something in and have to wait six months for it to be released. So it is a little smaller than it sounds when we talk about that. So I just wanted to make sure we were all on the same page with that. And so you were saying, Ben, in terms of the process and maybe automation or things like this, it's very tight to the next number of federal releases. Right, because we have milestones around having the change complete a couple weeks before. So it should be in a testable state by Tuesday for the Fedora 34 release on branch day. And then a few weeks after that it should be 100% code complete. And then we have a beta freeze and beta release and then a couple weeks and then a final release. So those are all very much tied around the idea of having schedule milestones, which doesn't quite fit. So they're like at a high level, the process really makes sense to just bring into. But then when you start getting into the details, it's when it starts getting really... You start getting a lot of the disconnects there. Christian? So I actually wanted to throw this in earlier, but my system crashed. So somebody probably mentioned Cgroups v1 versus v2. That's one of the things we haven't implemented that was a change proposal or a change proposal at the time. I think we're only going to be doing that with the next release, major release. So those are the kinds of things, especially in the email thread on the change proposal. It even came up to just the idea, do we even need the server addition anymore if CoroS becomes a real addition? And I think it's important to note that we still have some areas that are covered better by the server version, at least in my opinion. So for example, we don't have a great firewall story for configuring the firewall in Fedora CoroS yet. Because we don't ship Python, we don't have the firewall command. We don't have support for RPM modules currently. I'm not sure there was a blocker for that in terms that the LibDNF didn't provide a C API for it. I think they've now changed that. So maybe it's feasible that we actually get that soon. But there's just a few things that aren't really tested on Fedora CoroS as a standalone thing. I don't think, or at least I don't know if anybody frequently tests running cockpit on it. So these are the kinds of areas of friction I see in addition to the changes that we haven't been catching up with. I just wanted to throw that in here, that there's still some work to do. Obviously, I'd love for Fedora CoroS to become a full-blown addition as soon as possible. This goes to the politics of additions as well. I think we had on the develop list, we basically, the Fedora server addition had kind of fallen out of attention of anybody. And we were kind of thinking that without that amount of attention, it should be de-additioned. And the surprising result of saying that is suddenly it's got a lot of attention right now. We'll see if that lasts, but they're actually, they're people working on it again. And a lot of non-Red Hat community people with enthusiasm for it, which is great. Yeah, so Colin's comment, we don't want to change the addition status to the server addition status. I think that's true. But we also want to have a crisp, part of the point of additions is when you go to get Fedora, you should easily see, oh, I'm going to do this, I want this one. And so we want to have a crisp definition that can, there needs to be a 30-second explanation of whether someone should go to Fedora CoroS or Fedora server when they look at Fedora. And so again, we don't need to come up with that right now, but that should be part of this process here. And it's part of the reason we don't have like a KDE desktop addition, because we use a different desktop technology is not the kind of thing we're looking for here. It should be use case, what are you trying to do? What kind of user are you? Kind of focus things. So yeah, this is going to sit beside Fedora server at least for a while. And so it should make sense doing that. Which also means it doesn't have to solve all the same problems that Fedora server does. Like if modularity isn't a thing we care about, awesome. That's good for us. All right. So I think to maybe close the topic around like change. And I think we can maybe summarize in like we Fedora CoroS wants to participate in the change proposal. And it would be beneficial I think for everyone in the community. So there's probably a bit more discussion and trying to find a good middle ground and to how we can do that. Is that something we can discuss further with you, Ben? I would like to take it a step further unless Ben tries to kill me when I say this, which is I think we should develop a async change process that sits either within or next to the regular change process and use this as a way to pilot it. And I think we should explicitly say that we want that. Okay, I was trying to be a bit more. I'm trying to nod to you. Let's do it. Ben is making skeptical faces, but not daggers. Right. Awesome. Perfect. I'm glad you wore the shirt. All right. So I think it's worth spending a bit of time also on the release criteria and release brokers and go no go and how that looks like for us in Fedora CoroS. Anyone wants to maybe give a kind of status of what we currently do there? Oh, I can do it. Okay. My feeling is that we currently mostly rely. So as Simon was saying, we have like this Github issue tracker where users can raise bugs and say, yeah, this is broken. So I guess maybe the first thing to talk about is like the relationship between the streams. I think that's really key to our release criteria or go no go process would look like. It's like the relationship between the next testing and stable stream and how they work together. So we expect users to try the next version of Fedora CoroS and report anything that would be a potential blocker or potential issue. And if we have like, if we experience some issues in, for example, in the next stream, that would block this stream from being promoted to the testing stream. If there are like serious issue in the testing stream, that would block that content to be promoted to the stable stream. I think that's currently the kind of process we have in place to make sure that the stable stream is really stable and that we don't break users' content. And I don't know if we have like a formal process where we actually review this. I think it's more, maybe during the weekly IRC community meeting, there are some discussions on that. Christian, you want to go ahead? Yeah, I kind of wanted to focus a little bit on the relationship between our Fedora change proposal process and the CoroS enhancements repository that we have. So I think in terms of process, it would be great if we looked at our, as the Fedora CoroS team, if we looked at our enhancement repository and the enhancement and those that also affect upstream Fedora, we should then upstream as in those enhancement proposals should become a Fedora change proposal so they, you know, so we don't have divergence there. And then likewise, the other way around, there should be some process in making sure that change proposals in Fedora are also reviewed, or at least they're on the radar of the CoroS team. So we don't, and probably we could have probably done better with this because some of those changes we kind of only noticed rather late and then we didn't implement them because, yeah, because of that rolling release and updateability thing. So, yeah, I think it would be great to kind of just create a process for these things and obviously make sure that a change proposal for Fedora should also be valid if applicable for Fedora CoroS. So we don't have this divergence in the future that we don't catch up with Fedora changes. Thanks, Goli. Lamont, you were talking about bugs initially, right? Do we actually make a conscious decision not to have a Fedora CoroS component in a bug cell? I don't remember this. We did, yeah, and I understand that. I mean, it feels like in 90% of the cases, we'll have an RPM component that corresponds to that, so we can at least just, you know, like, ignition chips as an RPM and stuff like that, right? And if we hit, you know, a user hits an Azure bug, like you can file against Afterburn and we can roll it up as a blocker bug or something, but we definitely have the issue, right? It's like, we do ship some bits that aren't RPMs, but it feels like we can just pick a random component, maybe RPMs must be used to come against. I don't know, like as far as just bridging, instead of like inventing a GitHub to, like, some process for Fedora, I mean, I don't know, I actually feel very conflicted about this because I find Bugzilla much very productive, but I definitely understand that people want to work with free and open source software websites to use their free and open source software operating system. So, like, at least Bugzilla is finally open source.  Yeah, I think we do have some component in Bugzilla, but basically when somebody tries to open an issue there, it directs them to the GitHub issue tracker, but they can still create an issue.  Yeah, so one thing that is, as you were talking about the relation between multiple streams, which is testing stable and next. So, in the regular release process that we have, we kind of maintain a, I mean, so as to talk about the quality, we kind of maintain a set criteria. So if something breaks, according to that criteria, we kind of call that a blocker. So like, for example, if Rohit doesn't boot, then Rohit is never getting to that branch state where we can pull it off and start testing. That way we maintain some of these criteria into this link. So currently, it will be great to have some of these basic criteria set for multiple streams. So you can have, let's say this testing stream should be able to run a container, a service, people should be able to auto log in.  And if they break, then we kind of go ahead and say this thing is not working for some reason. But most of it is anyway covered by CI. So I guess on one end that part is solved. However, if something breaks, because in the last test day, we have been able to list some bugs which locate some of the packages. But here's the thing, you know, not all of them can be caught by CI. Some of them can be picked up from the change set. If something comes up on the enhancement, we can test them on a regular test stream or something. And we can roll them out as a part of blocker processing. This is exactly what it is. Thank you. Jonathan. Hey, I'm Jonathan. I work on CoreOS, Federal CoreOS and Red CoreOS. I just wanted to raise visibility on the... So Climat was talking about the three production streams. We also have development streams and mechanical streams. And what that means basically is streams that are less... I mean, we do pay attention to them, but the goal is to be exposed to problems much early on. So we have a raw high stream now, for example, which tracks through our raw high. And we have actually found bugs already there before branching, which is already huge progress compared to what we had before. But yeah, I do agree. There's still a lot of work to be done there to integrate more with Fedora. And the one link that Benjamin put into the chat there is an example of how we do that when we track the Fedora 34 change proposals and make sure we look over those and make sure whatever is going to affect us, we're aware of it. And if we need to talk to be part of the conversation upstream, then we definitely should do that. I think a big part of the problem is we're just not talking enough on the DEVEL mailing list to be like, oh guys, let's make sure this also works on Fedora CoreOS. Jeff? Sorry, I didn't introduce myself earlier. Jeff Ligon, I'm a manager at Red Hat for the ARCOS CoreOS and containers teams. So this divergence that we're talking about between the process for CoreOS and Fedora, is there any kind of tradeoff that we're talking about in becoming a top level addition where it becomes the CoreOS teams responsibility to maintain that anything that is being considered for a Fedora change request does get reviewed by CoreOS? I heard Matthew earlier mention that it's nice to have a 30 second pitch or something about the use case of this and why it's different as being the feature of being a CoreOS addition. And so I think that's more of a feature than a bug. But I am wondering where the responsibility lies on whether or not something should be considered by CoreOS if that falls on the CoreOS team or in Fedora in general to discuss whether or not it should go towards the CoreOS addition. Are we surrendering some kind of decision making ability for in return for becoming a top level addition? Or are we just making this a top level addition for the consideration and the naming and the celebrity of being at an April footing with other additions, right? So I'd say to answer that yes and no. We generally give additions and non-addition variants some latitude in diverging from sort of what the base is when it makes sense for their use case. It was things like using the BSD kernel instead of the Linux kernel, for example, that might be an issue. But by and large, if there's a good reason why you can't or don't want to do it, we're not generally going to force that in most cases. That said, I think there is some marketing and user experience benefit for CoreOS to be as close to what all the other Fedora variants look like in terms of configuration and package versions, things like that. So it's really sort of a case by case basis. And I don't know to what degree you sort of evaluate each update that comes through now in terms of obviously Fedora CoreOS uses a much smaller overall universe of packages. So I'm guessing you're not looking at each individual update as it comes out and saying, do we want to pluck this yes or no?  I guess this is the short answer. I think Timothy, you were next. I'm sorry, I'm muted. Okay, let's go again. So that's on the topic of release criteria and which change we look at and everything. And I think the release criteria, we have that in CI mostly.  So concurrent containers or things like that. So it's not even an option for us to ship that. It shouldn't be possible. And then the, so do we look at the dates? I'll say yes, we basically look at every single release we ship and try. We say we have big, well, not so much like a long process, but that we have a process to make sure that each update we ship is good. And we try to improve that all the time. So I'm not saying that Fedora isn't tested. But also that Fedora is is more is much, much more tested in terms that we have a restricted package set. So of course we can do that. But we, we spend a lot more time doing that. So it's ends and so on the other side, the for the changes themselves for the bugs, we also have more options when we have, when we have issues and we can, we can like cherry pick or or I would say discuss specific issues with more options and regular Fedora has because we can refuse to ship the version or skip a version or force an update to a new version. That's something Fedora regular Fedora cannot do, sir. It's, it's a bit of a different perspective around what we ship. Okay, I think Benjamin you were next to go. For those who were around during some of the initial discussions a couple of years ago, I think it's worth noting that we have scaled back our ambitions in terms of how finally we're tuning the package set. So for the most part, we are, we're snapshotting Bode stable into testing and then that promotes to the stable channel two weeks later, stable stream. In some cases, mostly with packages we maintain ourselves like ignition releases will lead Bode stable. In some cases where there's a regression of some sort, then we will pin an older version. So packages will trail both Bode stable and will work with the package maintainer to get that bug fixed. So generally packages do not trail stable or not pinned for an extended period of time. A place where we will tend to diverge a little bit more is that we have a pile of post processing that happens. We will drop will modify config files in some cases that are shipped as part of packages will sometimes delete files out of packages. Well, dropping it of course additional config. There's a get repo that has essentially a whole tree of trees of things we're doing to the file system. So there we tend to be somewhat more aggressive but the package set itself is fairly vanilla Bode stable with a bit of an additional lay for the two week promotion timing. All right. So do we want to add anything on that topic. I think so from, from what I look at, I kind of agree with Timothy that we have mostly everything is in CI. I think we could do with maybe having some explicit or at least write down what are the like, like really the few things that we really care. And that we just so that there is a clear, a clear list of our criteria and what we are checking and that's maybe something to do on our side. So yeah, thanks Micah for the reminder. I like a few over stuff. I think we, we touched a bit already how do we coordinate with other teams so dogs marketing translation magazine web and things like that. But can be there's anyone wants to to share opinions on this like how we coordinate with other teams. It might be good to have somebody who checks in with the mind share meetings regularly. And that is all these things listed in the other teams here are our federal mind share teams. So having somebody who goes to the mind share meetings regularly would probably be a good way to make sure that connection happens. I can actually take this out. You know, because I have been a mind share representative by sometime now. I actually know folks who are working in this specific areas and have been contributing for some time. So I might be able to help this. Okay, cool. I think that's a good idea. All right, so I guess the next steps on this is go and and I've been with with trying to get to craft a new, a new change, change process. And gone. I think in general, I was looking through our additions policy and everything is pretty far along on that list. There's not anywhere I see is like a huge gaps. It's because it's a lot of working on details here things I feel pretty positive about this. Also, the other thing is I wore this shirt today and I realized it wasn't on camera, but I wanted to make sure I showed off here before we end the meeting. Yeah, it's appropriate. Yeah, so really, like, I think the next few things is going to try to at least get a draft or at least start the conversation on the change proposal process and how it would look like. I think we can do better also into like the release blocker and risk right there. We have something a bit more explicit and talk with I might reach out to you cement all and like try to to see from the federal QA point of view. What what you would like and how we can help with that. Great. I think we reached the time. So I wanted to thanks everyone for your contribution. I think it was really quite conversation like a lot of good ideas and good exchange. So thank you everyone for participating and joining spending the time with us. Awesome. I'll stop it recording shortly for the Red Hat CoroS team proper. We're going to have the retro in 10 minutes on the other Google Meet URL. So sticker, please make yourself available for that because we'd love to know how to make these virtual Facebook sessions better. So yeah, just to say again thank you all for attending and contributing to the discussion. Have a great day. We'll see you on online I guess. Thanks. Come on for.