Getting your changes into openSUSE Leap and SLE
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Kocman, Lubos
What needs to happen to get your change into SUSE Linux Enterprise 15 and related openSUSE Leap.
 OK, starting now. Hello, guys. Welcome to my talk. It's about getting changes into open to the leap, 15.3 and newer, and to Slee, which we can. And let me tell you something about myself. I am Luboszko Cotsman. I work as a release manager for open to the leap. Let me maybe screen share. And I basically started Linux since people were talking about it. With Manrak Linux 9.1, it was attached to one of the magazines that I was reading. Otherwise, I used to be a release engineer for L6 and 7 in the past. And I was also shortly involved in the beginnings of Fedora modularity. And I was involved in the Czech open-storey user group back then when I was kind of into Slurries. So let's check the agenda for today. You may have noticed, but leap 15.3 is relatively complex. There's a lot of projects that kind of maybe and leap. And the goal here is to basically guide you for these projects, tell you what they are used for, how to contribute to them. So we are on the same page. And by the way, most of the information that I'll be talking about can be found on the open to the packaging for a leap wiki page. So if something's incorrect there, or if you like to explain it also, feel free to contribute to the page. Any help is appreciated. So let's talk about how we distribute both nowadays. So the line on the top is tumbleweed or factory if you want to. And for us, the important part is the bottom, right? Here, when we are talking about leap 15.3. So one of the packages roughly is binary inherited from Susie Slee 15 from all service packs. So just seeing 15.3.3 is kind of incorrect here because it's sp0, sp0, update, sp1, sp1, sp2, sp2, sp3. It makes the Sleek.co stream plus package hub that's roughly two threads. And the last little dot on the bottom, if you can see my cursor, is the leap branding, kivi files, anything related to product builds, or packages that we would like to explicitly for from Sleek because we want to keep maybe different behavior. There are a few. And they are not here also in package hub, but let's talk about it a little bit later. The general idea is that Sleek and package hub makes new leap. And since we were building package hub from leap 15.3.3, we always copy the packages. You're thinking that just continuing in this way actually makes sense. So that's why we are reusing that way. We are looking for ways to simplify it and improve it, make it a little bit faster because it's not ideal the way how we build right now. And we want to make it a little bit better in 15.4. So the actual structure, I've mentioned the three projects. So we can see them on the top. OpenSuselip 15.3, roughly 166 packages. What's different from the 15.2 is that we are actually now building all of the arches with the exception of Arm V7 in there. So we have S390 there, and then there is the non-free project, which has the non-free parts that would be Discord, Steam, and others. It's roughly 30 packages, or exactly 30 packages. Sorry. Then the backwards, that's almost 10,000 packages. This is basically the place for most of the leap development happens. So if you actually submit submission and leap, it will be redirected. I'll talk about the redirection later. Then it will most likely end up here, as long as it's a leap exclusive package. If it's sleep package, it will end up in sleep. Then we get to Sleek. So I'm actually using Suselip 15 SP Star because the redirection covers SP0 update. Sorry. 15 update, 15, 15 update, because we don't use SP0 in the project name, SP1, SP1 update, and so on. And that's roughly 5,000 packages if you're the duplicating individual updates to individual streams. And then what's interesting, and maybe you are not aware of that, is that we have now OpenSuselip step, which is actually used for fullerboot of OpenSuselip. Sorry, Suselip is an ex-enterprise because since we inherit binaries from Sleek, and Sleek doesn't have Rmv7, we have to find a way how to enable Rmv7 builds. So the way how we approach it is by rebuilding each layer of Sleek and actually adding Rmv7 support there. And so in the end, it's the duplicate of about 5,000 packages. But when I was checking the actual number, including all updates, it was more like 17,000 in each individual service pack. So it's quite large. And then the last project is under the OpenSuselip step namespace, and it's the front runner where we actually rebuild everything in a single layer, not in individual service packs. And this is where we are actually trying to develop the Rmv7. And we have also option to, we call it, in development versions, or some suggested fixes for Sleek for next service packs. So there is a little bit of flexibility where we can take some changes ahead. Because this bootstrap and rebuild takes quite a lot of time, and this disabilification really makes it shorter. And then if the change is considered that it may be dangerous at this point, we need more testing. Or it's not yet ready, or the currently development service pack is maybe in RC, and we cannot take the change in there. We can actually use this feature to enable the builds. And maybe we will use it for risk 5 enablement in the future, because we are in the point where this is already working. So this is roughly the structure I'm skipping images containers, I know about it. But let's talk about package submissions. And this is probably where you would contribute. If you would try to contribute to Rmv7 development, it would be one of the two projects on the bottom, most like the D Frontrunner. So details about the projects. OpenSuzali 15.3, I mentioned that there is only a few 160 packages or so. And it's the top level project, which contains most of the product configuration and branding and some product packages from Slee. We are using it for building DVDs. So it's sort of like umbrella project, which takes all artifacts from Slee, from back ports, and then makes deliverables. And there is one interesting part about the project. And it has the submit request mirroring. So if you are contributing to existing package, not the new one, and you submit something against OpenSuzali, just like in the example, OSE-SR opens Slee 15.3 GA in your package, it will actually detect where is the package coming from the origin of the package. And the submission will be redirected there. So you don't really have to think about where it is. But there are certain cases where if we are rebuilding the package, if we have it forked, you really want to send a submit request to the true origin, which could be Slee in case that we forked it. So now let's look at the largest one, which is backports, basically the new leap. So the nice part compared to 15.2 is now that we built package packages. This is the module on Slee side, the publishable part for Slee. And for leap, we built it in one project not twice like we used to before. And we were considering whether we should actually have these two layers or not. And even now, it's a question in 15.4, because the additional layer of being able to maybe put some extra branding on top of the backports and therefore have two different build configurations for package up and leap gives us a little bit of flexibility. There are some downsides as well, a little bit increased complexity. And as I recently heard, also the scheduler priority is different if you finish like FTP3 build in foreign project versus the same project, it's also a little bit of delay. And how to contribute to this new leap? So basically, I told you if it's an existing package, you just contribute to open Slee 15.3 GA. And if it's a new one, you have to be really explicit. But you can use backports to make sure, like in any case. But I really like the redirection, so I'm always advising to use it because it's a Slee package, like it will do the Slee submission for you. And for new packages, please use the actual destination. For whatever reason, you need to add new package to Slee, for example, because we are updating some software there which then has a new dependency. Specific Slee, I will show you on the next slide how to do that. If you are really putting something new to leap, then you really want backports. If you are adding some branding, then maybe top level leap project. And right now, the behavior is that if you would submit to 15.4 GA, which doesn't exist yet in OBS, but if it would actually land in the top level project, which I feel like is incorrect. So we may actually set default to backports, because this will be the case for most of the packages. So let's have a look at these Slee. Star, as I mentioned, it's basically layered structure. You don't see all these service packs here only. This is the predefined graphics from the slides. So it only fitted these four. But everything was once released. This was a Slee 15 GA. And then if there was an update to it, the package actually got updated through this Slee 15 update. So then it was Slee 15 GA plus updates. Then Slee 15, as people may be very basic gnome or something, then the package got forked in that project. So you can see how it's glued together through the inheritance. And there are some nice things about it, because we actually are supporting code streams in parallel, like DSP1 LTS, as I believe ended recently. And therefore, we are trying to minimize the amount of code streams that are supported by our maintenance team, which is a nice idea. But that makes it a little bit tricky when you are trying to contribute to Slee, because you need to understand where we want to place it, or you have to ask somebody to help you. Where should we put the package usually? I think this is on the next slide, actually. Usually, if you are thinking where to place it, the answer is if it's rebase, the country develops service packs of SP4 nowadays. If it's a library that we try to maintain across all code streams, then the answer is the latest supported service pack. So how to submit there? Again, if the package is not forked in LEAP, which will be, in the most cases, for Slee packages, we are trying to use the binaries from Slee. In as many cases as we can. You would just do submit request against LEAP 15.4, and then just name of the package, for example, Pesh. Pesh is coming from Slee. And this will actually directly submit the request to SUSE Slee SP4 SP3 update nowadays, because the latest batch was released in SP3 GA. And then the triggers review for SUSE Slee reviewers. And somebody has to manually run OSC Jump review, which is a plugin to OSC. That release team has. And it will actually show the currently open requests. And if it looks good, if it has issues or friends, I will go about details like what you need to have in that submit request to Slee. Then it will trigger the mirror. So the submission will be cloned on the internal instance. And then we have some sync of statuses and comments in place. That will basically make sure that the package, if it passes the workflow, you should know about it on the OBS site. There may be some bugs at the moment, but this is the idea. And then it's basically like any other submission which is created by SUSE Engineer. It will be triggered under the name of person who run the review. So in most cases, it will be me. But yeah. So about the Jump review, how it looks like. So this is the example output, for example, for Pesh. It's basically telling me about the change. And then I'm just looking if it has the issue reference, which we really have to have for every single Slee maintenance request. You need to have a bug reference. If you are doing version update, you will have to have some features referenced. But then if it has all of this, then we can accept it. And it just creates a new SR with new ID, but in different OBS instance, the internal one, which we refer to as IDS. Right now, this is fully manual just to make clear. So if I don't run it for two days, you have to wait for it. Maybe we should figure out some nice way how this doesn't depend on a Vodrelubo classification or not. But we can talk about it on release team meetings. So closer look at Slee. What's important when you are doing submission to Slee? That's the deadlines. And we try to actually have the same deadlines in Leap. So our alpha should be really related to that alpha, especially with deadlines. It should be exactly the same. So it feels natural to contribute to it. Because Slee may be a little bit more strict about when the new features should come in Leap. It's generally after beta, you should already delete packages. So deletions should be before. But if it's communicated properly, we take changes up until Rc. And then it should be really just backfixes to stabilize it as much as we can. On Slee, it's a little bit more strict. And we have to respect that. It was always the case. It's not that this is something new. And if it's a maintenance request or a late feature request, something that you would open around beta time or even later, which is happening all the time, there is something called ECO. And it may sound scary. We have it on Viki. So you can actually look for it, what it exactly means. But it's basically engineering change order, which requires some additional approvals. To you, it remains hidden. Because even if you have access to Jira, and I will show how it looks like later, you basically see just a feature. And then in behind, there is one extra Jira, which is blocking your Jira, which has subtasks for each reviewer. And right now, I believe it's for reviewers, something like security team, a level 3 support, and so on, who are saying whether change looks OK. There are weekly review meetings when they're actually going over all open DCOs. And once the approval is done, then we can proceed. It will be handed over to maintenance team, and so on and so on. Again, as I mentioned, all requests to sleep have to reference some issue. Either Jira, that would be JSC hash, and then the Jira ID. If you did request the open SUSE, sorry, Jira SUSE COM access, this open SUSE contributor, you may look there. If not, we could meet things on Monday. And now also Viki page for planning, for features for SP4, where we are referencing these features. And this is something that you should reference in DSR. Or the bug. For most bug fixes, to maintenance updates, you just need to reference the bugzilla. And that should be pretty fine. And again, if we will be rejecting this submit request, we are doing it with good intention, because we want to shorten the feedback loop. Otherwise, we would mirror it. It would get rejected. It would just take a few more days. Right now, we really need to do the filter, so we don't waste any once time. So how do these Jira looks like, especially for LEA-153? So if it's not a bug fix or CVE fix in general, but a version update, we need to have some sort of feature. And we have an open SUSE project within Jira, where we are tracking all of them. We know that this is not ideal, because requesting account takes some time. It's not that you can just log in and go there. We really have to make change on SUSE's LDAP, and so on, needs to be approved. Takes a few days. We are actually considering some public interface. Right now, Neil Gomp actually created the project LEAP slash features on the Pagger instance. We are considering if it could be the front end, where we would have all the features, and we would have to figure out some sort of sync probably manually in the beginning. But it would be probably more convenient. You could use your open SUSE login, just go there, create it, and then we would review them probably on our Mondays meetings, which I'm referencing here. We have it also on Wiki page. If you check the common entity, SLEE, feature, a change request, Wiki. And what we are doing is that we are collecting these features that are necessary for these version updates in SLEE. We are always monitoring if there is some progress, or what's the blocker. Talk about them. Talk about what's new, and just making sure that we are tracking everything that needs to be done to unblock progress on LEAP, the common entity part. This is the idea. Most feature requests are, hey, I need to update my package, and we need to update this version of library in SLEE. And this would be basically the case. So if you ever feel blocked on something, don't say, well, I will wait until SLEE updates it. Like, we can really request a change. There is good use case for it. I needed to update my software, so we can fix this back, for example, then this is exactly what is it used for. The attendees of these meetings are usually me, NEO, sometimes Gertian joins. I know Sara was there a few times as well, so feel free to join. I'm also considering maybe in the future to run it on slash bar rather than slash feature requests, because we have more attendance there, and it feels more natural to talk to these people. Just switch to this for half an hour, go through it. People can tell you their opinions, or maybe we can create some more requests if necessary. And I really want to be open about these. And in the end, it has to be tracked for Jira, but maybe we can use different front end, so it doesn't, you know, you don't have to really worry about the accounts. So we were talking about these origins. Sleep, backboard, we've also mentioned, front end or step. You know, Sleep, how do I check that? So I have also some examples here, which are a little bit tricky, like the LLVM. So you can use, we don't have forage manager in 15.3, so you can use OSC meta or the web browser. I will show it two slides after. And you would do OSC meta package, opens the ZLV 15.3 LLVM. You know that there is submit request redirection, so if you want to have it easy, just submit to leap. But, you know, if you really want to double check whether the package is not really a SLEEP package, you might recommend to use OSC meta. So there you would do LLVM, and you can grab it by project, or just, you know, it's the second line or first line. And you see that this package is coming from opens is a backwards SLEEP 15.3. So it seems like it's a community package, so it's a leap package. But in the end, this is one of the packages that we had to fork because of different, you know, expectations on SLEEP side and leap side, SLEEP has LLVM seven-year-old LLVM, and this is the meta package, you know, just saying which one is the default. And otherwise, the same versions of LLVM are available across both distributions, but we have different defaults, let's go this way. And now the question is, okay, so I see it's in SLEEP as well, it's in backwards, so where do I submit this submit request? And that's the tricky part, I guess, on the new model. So that really depends on some aspects. You can double check really quickly, like, and, you know, use common sense. Is it the identical sources? And if it's identical sources, then you'd probably know that we forked it because we need to rebuild it. Maybe we are utilizing the ESOPEN Susan macro, and we have something, you know, some different behavior on LEEP. And if they are different, then you know that we have an agreement to have completely different source code, like an LLVM case. And if it's completely different, then most likely the answer is that you want to, you know, contribute to SLEEP, sorry, because we have different sources, so we will work on these. If it's identical, then SLEEP is the answer, because we have to be in sync, and in most cases, we are doing forks, for example, because we have some extra multiple flavors, which we would like to have in LEEP and in package hub, but they are not supported in SLEEP side. So usually the SLEEP is the answer, and then we would, you know, copy the source code as soon as it's done and rebuild the package, so we can ship the additional flavors. And then if it's in SLEEP, and you see that, for example, the package just like here is coming from SLEEP15 SP1GA, which is EOL already, then that's tricky. Then I really recommend to sync up with us, but on the other hand, if you file a submit request to whatever even bits, SLEEP15 SP1GA, we will go for that review and we will say, oh, we probably need to send it to something newer. So in general, the answer is the latest supported service pack, or if you are doing rebase, the currently developed service pack, like SP4 in this case, for example. So it's a little bit tricky, and I know that it will require guidance, but we are here to help you. And again, as mentioned, we are reviewing every single submission, so it will be something suspicious. We will just let you know, and we have to redo it differently or help you to achieve what you need to achieve. Another case, branding packages, I've mentioned that are in LEAP, so this is very simple example. Again, you would do OSESR to LEAP153, just like in many, in the other cases. The only exception is really when we forward the package there, you have to think about where do I really want to, you know, update a code. So here just request to LEAP153, maintenance requests. So maintenance requests are currently tricky. So for previous code streams, you can just do SR against, let's say, LEAP15, I don't know, SP2 update, and it will work, but for SLEEP, 15 SP3 update, it currently doesn't work. We have a bug, and I'm discussing it without a build, how to get it fixed. Because if you do MR, it triggers the opens, as a maintenance request, and it doesn't get to SLEEP, so we have to improve this. But stay tuned, like it should be fixed within the next few days. And the maintenance work for documentation, including the SLEEP one, will be documented on the maintenance update process. Vicky, another way to check origin, I mentioned that you can do it also through web browser. So if you go to LEAP153 project, you can check the inherited wall. For packages that we are introducing in 153, it would be, or the branding packages, it would be the packages, but you want to see the inherited ones, because I told you, most of the LEAP is coming from backboards. And here, you just look for package and you see, oh, it's coming from SLEEP, or it's coming from backboards, and which service pack of SLEEP, this is the very first one, the zeroed service pack, it's just, we are not using SP0 in the name. So this is actually convenient way. One thing that I would like to say before discussion, because next step is just discussion, like listening to your pain points, and basically looking for some suggestions how to make this little bit more user friendly, contributor friendly, maybe it's the best word here. And I would like to ask you to join BARM, every single time when you have a moment, or when you want to discuss some of the issues, or hindrance, or whatever you have with contributing, there's always someone, and this is taken from half past 3 AM, and you can see CST time, and you can see that people are there, everybody's happy, it's just because we are from all around the globe. And now let's move to discussion, because otherwise this is the end of the presentation, let me switch then. And the new less room. Okay. Hey guys, can you hear me? We can hear you. Perfect, perfect, any questions? Like I know it's overwhelming, because there is a lot of information, so sorry for that, but unfortunately, this is how the new layout looks like. And if somebody has some questions, or something is still unclear, just ask. You know, this is why the discussion is more important than the actual slides, because we want to fix your problem, and not just, you know, talk about how it looks like. No one? Well. Yeah, Neil can talk about it a little bit, right? So Neil, let me give context to people. So Neil has mentioned this, one of the people who actually attend the meeting regularly, he's there every time. And you know, he has the experience with late features, not yet early features, because I think that we started relatively late, also the 15.3 had a really short development phase, because we could only start with sleepy top two, because of the NDA. So these days we will have much more time actually to work on some early features as well. Your turn, Neil. Okay.
 OK, starting now.  Hello, guys.  Welcome to my talk.  It's about getting changes into open to the leap, 15.3  and newer, and to Slee, which we can.  And let me tell you something about myself.  I am Luboszko Cotsman.  I work as a release manager for open to the leap.  Let me maybe screen share.  And I basically started Linux since people were talking  about it.  With Manrak Linux 9.1, it was attached to one of the  magazines that I was reading.  Otherwise, I used to be a release engineer for L6 and 7  in the past.  And I was also shortly involved in the beginnings of  Fedora modularity.  And I was involved in the Czech open-storey user group  back then when I was kind of into Slurries.  So let's check the agenda for today.  You may have noticed, but leap 15.3 is relatively  complex.  There's a lot of projects that kind of maybe and leap.  And the goal here is to basically guide you for  these projects, tell you what they are used for, how to  contribute to them.  So we are on the same page.  And by the way, most of the information that I'll be  talking about can be found on the open to the packaging for  a leap wiki page.  So if something's incorrect there, or if you like  to explain it also, feel free to contribute to the page.  Any help is appreciated.  So let's talk about how we distribute both nowadays.  So the line on the top is tumbleweed or factory if you  want to.  And for us, the important part is the bottom, right?  Here, when we are talking about leap 15.3.  So one of the packages roughly is binary inherited from  Susie Slee 15 from all service packs.  So just seeing 15.3.3 is kind of incorrect here because it's  sp0, sp0, update, sp1, sp1, sp2, sp2, sp3.  It makes the Sleek.co stream plus package hub that's  roughly two threads.  And the last little dot on the bottom, if you can see my  cursor, is the leap branding, kivi files, anything  related to product builds, or packages that we would like to  explicitly for from Sleek because we want to keep maybe  different behavior.  There are a few.  And they are not here also in package hub, but let's talk  about it a little bit later.  The general idea is that Sleek and package hub makes new  leap.  And since we were building package hub from leap 15.3.3,  we always copy the packages.  You're thinking that just continuing in this way actually  makes sense.  So that's why we are reusing that way.  We are looking for ways to simplify it and improve it,  make it a little bit faster because it's not ideal the  way how we build right now.  And we want to make it a little bit better in 15.4.  So the actual structure, I've mentioned the three projects.  So we can see them on the top.  OpenSuselip 15.3, roughly 166 packages.  What's different from the 15.2 is that we are actually now  building all of the arches with the exception of Arm V7 in  there.  So we have S390 there, and then there is the non-free  project, which has the non-free parts that would be  Discord, Steam, and others.  It's roughly 30 packages, or exactly 30 packages.  Sorry.  Then the backwards, that's almost 10,000 packages.  This is basically the place for most of the leap development  happens.  So if you actually submit submission and leap, it will  be redirected.  I'll talk about the redirection later.  Then it will most likely end up here, as long as it's a leap  exclusive package.  If it's sleep package, it will end up in sleep.  Then we get to Sleek.  So I'm actually using Suselip 15 SP Star because the redirection  covers SP0 update.  Sorry.  15 update, 15, 15 update, because we don't use SP0 in the  project name, SP1, SP1 update, and so on.  And that's roughly 5,000 packages if you're the  duplicating individual updates to individual streams.  And then what's interesting, and maybe you are not aware of  that, is that we have now OpenSuselip step, which is  actually used for fullerboot of OpenSuselip.  Sorry, Suselip is an ex-enterprise because since we  inherit binaries from Sleek, and Sleek doesn't have  Rmv7, we have to find a way how to enable Rmv7 builds.  So the way how we approach it is by rebuilding each layer of  Sleek and actually adding Rmv7 support there.  And so in the end, it's the duplicate of about 5,000  packages.  But when I was checking the actual number, including all  updates, it was more like 17,000 in each individual  service pack.  So it's quite large.  And then the last project is under the OpenSuselip step  namespace, and it's the front runner where we actually  rebuild everything in a single layer, not in individual  service packs.  And this is where we are actually trying to  develop the Rmv7.  And we have also option to, we call it, in development  versions, or some suggested fixes for Sleek for next  service packs.  So there is a little bit of flexibility where we can take  some changes ahead.  Because this bootstrap and rebuild takes quite a lot of  time, and this disabilification really makes it  shorter.  And then if the change is considered that it may be  dangerous at this point, we need more testing.  Or it's not yet ready, or the currently development  service pack is maybe in RC, and we cannot take the  change in there.  We can actually use this feature to enable the builds.  And maybe we will use it for risk 5 enablement in the  future, because we are in the point where this is already  working.  So this is roughly the structure I'm skipping images  containers, I know about it.  But let's talk about package submissions.  And this is probably where you would contribute.  If you would try to contribute to Rmv7 development, it  would be one of the two projects on the bottom, most  like the D Frontrunner.  So details about the projects.  OpenSuzali 15.3, I mentioned that there is only a few  160 packages or so.  And it's the top level project, which contains most of the  product configuration and branding and some  product packages from Slee.  We are using it for building DVDs.  So it's sort of like umbrella project, which takes all  artifacts from Slee, from back ports, and then makes  deliverables.  And there is one interesting part about the project.  And it has the submit request mirroring.  So if you are contributing to existing package, not the new  one, and you submit something against OpenSuzali, just like  in the example, OSE-SR opens Slee 15.3 GA in your package,  it will actually detect where is the package coming from the  origin of the package.  And the submission will be redirected there.  So you don't really have to think about where it is.  But there are certain cases where if we are rebuilding the  package, if we have it forked, you really want to send a  submit request to the true origin, which could be Slee in  case that we forked it.  So now let's look at the largest one, which is backports,  basically the new leap.  So the nice part compared to 15.2 is now that we built  package packages.  This is the module on Slee side, the publishable part for  Slee.  And for leap, we built it in one project not twice like we  used to before.  And we were considering whether we should actually have  these two layers or not.  And even now, it's a question in 15.4, because the  additional layer of being able to maybe put some extra  branding on top of the backports and therefore have two  different build configurations for package up and leap gives  us a little bit of flexibility.  There are some downsides as well, a little bit increased  complexity.  And as I recently heard, also the scheduler priority is  different if you finish like FTP3 build in foreign project  versus the same project, it's also a little bit of delay.  And how to contribute to this new leap?  So basically, I told you if it's an existing package, you  just contribute to open Slee 15.3 GA.  And if it's a new one, you have to be really explicit.  But you can use backports to make sure, like in any case.  But I really like the redirection, so I'm always  advising to use it because it's a Slee package, like it  will do the Slee submission for you.  And for new packages, please use the actual destination.  For whatever reason, you need to add new package to Slee,  for example, because we are updating some software there  which then has a new dependency.  Specific Slee, I will show you on the next slide  how to do that.  If you are really putting something new to leap, then  you really want backports.  If you are adding some branding, then maybe top level leap  project.  And right now, the behavior is that if you would submit to  15.4 GA, which doesn't exist yet in OBS, but if it would  actually land in the top level project, which I feel like  is incorrect.  So we may actually set default to backports, because this  will be the case for most of the packages.  So let's have a look at these Slee.  Star, as I mentioned, it's basically layered structure.  You don't see all these service packs here only.  This is the predefined graphics from the slides.  So it only fitted these four.  But everything was once released.  This was a Slee 15 GA.  And then if there was an update to it, the package  actually got updated through this Slee 15 update.  So then it was Slee 15 GA plus updates.  Then Slee 15, as people may be very basic gnome or something,  then the package got forked in that project.  So you can see how it's glued together  through the inheritance.  And there are some nice things about it, because we  actually are supporting code streams in parallel,  like DSP1 LTS, as I believe ended recently.  And therefore, we are trying to minimize  the amount of code streams that are supported  by our maintenance team, which is a nice idea.  But that makes it a little bit tricky  when you are trying to contribute to Slee,  because you need to understand where we want to place it,  or you have to ask somebody to help you.  Where should we put the package usually?  I think this is on the next slide, actually.  Usually, if you are thinking where to place it,  the answer is if it's rebase, the country  develops service packs of SP4 nowadays.  If it's a library that we try to maintain across all code  streams, then the answer is the latest supported service pack.  So how to submit there?  Again, if the package is not forked in LEAP,  which will be, in the most cases, for Slee packages,  we are trying to use the binaries from Slee.  In as many cases as we can.  You would just do submit request against LEAP 15.4,  and then just name of the package, for example,  Pesh.  Pesh is coming from Slee.  And this will actually directly submit  the request to SUSE Slee SP4 SP3 update nowadays,  because the latest batch was released in SP3 GA.  And then the triggers review for SUSE Slee reviewers.  And somebody has to manually run OSC Jump review, which  is a plugin to OSC.  That release team has.  And it will actually show the currently open requests.  And if it looks good, if it has issues or friends,  I will go about details like what you need to have  in that submit request to Slee.  Then it will trigger the mirror.  So the submission will be cloned on the internal instance.  And then we have some sync of statuses and comments in place.  That will basically make sure that the package,  if it passes the workflow, you should know about it on the OBS  site.  There may be some bugs at the moment, but this is the idea.  And then it's basically like any other submission which  is created by SUSE Engineer.  It will be triggered under the name of person  who run the review.  So in most cases, it will be me.  But yeah.  So about the Jump review, how it looks like.  So this is the example output, for example, for Pesh.  It's basically telling me about the change.  And then I'm just looking if it has the issue reference, which  we really have to have for every single Slee maintenance  request.  You need to have a bug reference.  If you are doing version update, you  will have to have some features referenced.  But then if it has all of this, then we can accept it.  And it just creates a new SR with new ID,  but in different OBS instance, the internal one,  which we refer to as IDS.  Right now, this is fully manual just to make clear.  So if I don't run it for two days,  you have to wait for it.  Maybe we should figure out some nice way  how this doesn't depend on a Vodrelubo classification  or not.  But we can talk about it on release team meetings.  So closer look at Slee.  What's important when you are doing submission to Slee?  That's the deadlines.  And we try to actually have the same deadlines in Leap.  So our alpha should be really related to that alpha,  especially with deadlines.  It should be exactly the same.  So it feels natural to contribute to it.  Because Slee may be a little bit more strict about when  the new features should come in Leap.  It's generally after beta, you should already  delete packages.  So deletions should be before.  But if it's communicated properly,  we take changes up until Rc.  And then it should be really just backfixes to stabilize it  as much as we can.  On Slee, it's a little bit more strict.  And we have to respect that.  It was always the case.  It's not that this is something new.  And if it's a maintenance request or a late feature  request, something that you would open around beta time  or even later, which is happening all the time,  there is something called ECO.  And it may sound scary.  We have it on Viki.  So you can actually look for it, what it exactly means.  But it's basically engineering change order, which  requires some additional approvals.  To you, it remains hidden.  Because even if you have access to Jira,  and I will show how it looks like later,  you basically see just a feature.  And then in behind, there is one extra Jira,  which is blocking your Jira, which  has subtasks for each reviewer.  And right now, I believe it's for reviewers,  something like security team, a level 3 support, and so on,  who are saying whether change looks OK.  There are weekly review meetings when they're actually  going over all open DCOs.  And once the approval is done, then we can proceed.  It will be handed over to maintenance team,  and so on and so on.  Again, as I mentioned, all requests to sleep  have to reference some issue.  Either Jira, that would be JSC hash, and then the Jira ID.  If you did request the open SUSE, sorry,  Jira SUSE COM access, this open SUSE contributor,  you may look there.  If not, we could meet things on Monday.  And now also Viki page for planning, for features for SP4,  where we are referencing these features.  And this is something that you should reference in DSR.  Or the bug.  For most bug fixes, to maintenance updates,  you just need to reference the bugzilla.  And that should be pretty fine.  And again, if we will be rejecting this submit request,  we are doing it with good intention,  because we want to shorten the feedback loop.  Otherwise, we would mirror it.  It would get rejected.  It would just take a few more days.  Right now, we really need to do the filter,  so we don't waste any once time.  So how do these Jira looks like, especially for LEA-153?  So if it's not a bug fix or CVE fix in general,  but a version update, we need to have some sort of feature.  And we have an open SUSE project within Jira,  where we are tracking all of them.  We know that this is not ideal, because requesting account  takes some time.  It's not that you can just log in and go there.  We really have to make change on SUSE's LDAP,  and so on, needs to be approved.  Takes a few days.  We are actually considering some public interface.  Right now, Neil Gomp actually created the project LEAP  slash features on the Pagger instance.  We are considering if it could be the front end,  where we would have all the features,  and we would have to figure out some sort of sync probably  manually in the beginning.  But it would be probably more convenient.  You could use your open SUSE login, just go there,  create it, and then we would review them probably  on our Mondays meetings, which I'm referencing here.  We have it also on Wiki page.  If you check the common entity, SLEE, feature,  a change request, Wiki.  And what we are doing is that we are collecting these features  that are necessary for these version updates in SLEE.  We are always monitoring if there is some progress,  or what's the blocker.  Talk about them.  Talk about what's new, and just making sure  that we are tracking everything that  needs to be done to unblock progress on LEAP,  the common entity part.  This is the idea.  Most feature requests are, hey, I need to update my package,  and we need to update this version of library in SLEE.  And this would be basically the case.  So if you ever feel blocked on something,  don't say, well, I will wait until SLEE updates it.  Like, we can really request a change.  There is good use case for it.  I needed to update my software, so we can fix this back,  for example, then this is exactly what is it used for.  The attendees of these meetings are usually me, NEO,  sometimes Gertian joins.  I know Sara was there a few times as well,  so feel free to join.  I'm also considering maybe in the future  to run it on slash bar rather than slash feature requests,  because we have more attendance there,  and it feels more natural to talk to these people.  Just switch to this for half an hour,  go through it.  People can tell you their opinions,  or maybe we can create some more requests if necessary.  And I really want to be open about these.  And in the end, it has to be tracked for Jira,  but maybe we can use different front end,  so it doesn't, you know, you don't have to really worry  about the accounts.  So we were talking about these origins.  Sleep, backboard, we've also mentioned, front end or step.  You know, Sleep, how do I check that?  So I have also some examples here,  which are a little bit tricky, like the LLVM.  So you can use, we don't have forage manager in 15.3,  so you can use OSC meta or the web browser.  I will show it two slides after.  And you would do OSC meta package,  opens the ZLV 15.3 LLVM.  You know that there is submit request redirection,  so if you want to have it easy, just submit to leap.  But, you know, if you really want to double check  whether the package is not really a SLEEP package,  you might recommend to use OSC meta.  So there you would do LLVM,  and you can grab it by project,  or just, you know, it's the second line or first line.  And you see that this package is coming from opens  is a backwards SLEEP 15.3.  So it seems like it's a community package,  so it's a leap package.  But in the end, this is one of the packages  that we had to fork because of different, you know,  expectations on SLEEP side and leap side,  SLEEP has LLVM seven-year-old LLVM,  and this is the meta package, you know,  just saying which one is the default.  And otherwise, the same versions of LLVM  are available across both distributions,  but we have different defaults, let's go this way.  And now the question is, okay, so I see it's in SLEEP as well,  it's in backwards, so where do I submit this submit request?  And that's the tricky part, I guess, on the new model.  So that really depends on some aspects.  You can double check really quickly,  like, and, you know, use common sense.  Is it the identical sources?  And if it's identical sources,  then you'd probably know that we forked it  because we need to rebuild it.  Maybe we are utilizing the ESOPEN Susan macro,  and we have something, you know,  some different behavior on LEEP.  And if they are different, then you know  that we have an agreement to have  completely different source code, like an LLVM case.  And if it's completely different,  then most likely the answer is that you want to,  you know, contribute to SLEEP, sorry,  because we have different sources,  so we will work on these.  If it's identical, then SLEEP is the answer,  because we have to be in sync, and in most cases,  we are doing forks, for example,  because we have some extra multiple flavors,  which we would like to have in LEEP and in package hub,  but they are not supported in SLEEP side.  So usually the SLEEP is the answer,  and then we would, you know, copy the source code  as soon as it's done and rebuild the package,  so we can ship the additional flavors.  And then if it's in SLEEP, and you see that,  for example, the package just like here  is coming from SLEEP15 SP1GA, which is EOL already,  then that's tricky.  Then I really recommend to sync up with us,  but on the other hand, if you file a submit request  to whatever even bits, SLEEP15 SP1GA,  we will go for that review and we will say,  oh, we probably need to send it to something newer.  So in general, the answer is the latest  supported service pack, or if you are doing rebase,  the currently developed service pack,  like SP4 in this case, for example.  So it's a little bit tricky,  and I know that it will require guidance,  but we are here to help you.  And again, as mentioned,  we are reviewing every single submission,  so it will be something suspicious.  We will just let you know,  and we have to redo it differently  or help you to achieve what you need to achieve.  Another case, branding packages,  I've mentioned that are in LEAP,  so this is very simple example.  Again, you would do OSESR to LEAP153,  just like in many, in the other cases.  The only exception is really when we forward the package there,  you have to think about where do I really want to,  you know, update a code.  So here just request to LEAP153, maintenance requests.  So maintenance requests are currently tricky.  So for previous code streams,  you can just do SR against, let's say,  LEAP15, I don't know, SP2 update,  and it will work, but for SLEEP,  15 SP3 update, it currently doesn't work.  We have a bug, and I'm discussing it  without a build, how to get it fixed.  Because if you do MR, it triggers the opens,  as a maintenance request, and it doesn't get to SLEEP,  so we have to improve this.  But stay tuned, like it should be fixed within the next few days.  And the maintenance work for documentation,  including the SLEEP one,  will be documented on the maintenance update process.  Vicky, another way to check origin,  I mentioned that you can do it also through web browser.  So if you go to LEAP153 project,  you can check the inherited wall.  For packages that we are introducing in 153,  it would be, or the branding packages,  it would be the packages, but you want to see  the inherited ones, because I told you,  most of the LEAP is coming from backboards.  And here, you just look for package and you see,  oh, it's coming from SLEEP, or it's coming from backboards,  and which service pack of SLEEP,  this is the very first one, the zeroed service pack,  it's just, we are not using SP0 in the name.  So this is actually convenient way.  One thing that I would like to say before discussion,  because next step is just discussion,  like listening to your pain points,  and basically looking for some suggestions  how to make this little bit more user friendly,  contributor friendly, maybe it's the best word here.  And I would like to ask you to join BARM,  every single time when you have a moment,  or when you want to discuss some of the issues,  or hindrance, or whatever you have with contributing,  there's always someone, and this is taken  from half past 3 AM, and you can see CST time,  and you can see that people are there, everybody's happy,  it's just because we are from all around the globe.  And now let's move to discussion,  because otherwise this is the end of the presentation,  let me switch then.  And the new less room.  Okay.  Hey guys, can you hear me?  We can hear you.  Perfect, perfect, any questions?  Like I know it's overwhelming,  because there is a lot of information,  so sorry for that, but unfortunately,  this is how the new layout looks like.  And if somebody has some questions,  or something is still unclear, just ask.  You know, this is why the discussion is more important  than the actual slides, because we want to fix your problem,  and not just, you know, talk about how it looks like.  No one?  Well.  Yeah, Neil can talk about it a little bit, right?  So Neil, let me give context to people.  So Neil has mentioned this,  one of the people who actually attend the meeting regularly,  he's there every time.  And you know, he has the experience with late features,  not yet early features,  because I think that we started relatively late,  also the 15.3 had a really short development phase,  because we could only start with sleepy top two,  because of the NDA.  So these days we will have much more time actually  to work on some early features as well.  Your turn, Neil.  Okay.
openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_0_131.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_132_335.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_336_635.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_636_707.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_708_755.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_756_887.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_888_1487.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_1488_2315.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_2316_4487.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_4488_8771.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_8772_10499.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_10500_13595.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_13596_17999.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_18000_18839.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_18840_23075.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_23076_26687.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_26688_28859.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_28860_31811.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_31812_33311.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_33312_34139.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_34140_35135.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_35136_35519.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_35520_36251.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_36252_36791.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_36792_36887.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_36888_36947.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_36948_37211.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_37212_37499.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_37500_37547.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_37548_37619.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_37620_37727.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_37728_37859.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_37860_38279.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_38280_38363.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_38364_38411.png openSUSE_Virtual_Conference_2021_-_Live__Getting_y_-0j8ZN0_518_38412_38534.png