All right, so welcome back everyone. So we're going to have a cross collaboration panel, and we might have a few, few people joining us.

And who might come a little late but anyway, I want to introduce introduce you to the panel that we have. So, we have myself Douglas smile. I do some, I'm going to sort of moderate this. And, and then we have Adrian Schroeder Adrian works on OBS.

So Ben, Ben cotton your bends the release manager for for door with Matthew Miller, just coming in here. We also have Dan sir Mac I'm not sure if I'm saying that correct and please feel free to depends on how you how you define that but close enough.

Yeah, and it looks like Neil Gompa has joined us as well. So, thank you. Thank you all for being a part of this panel.

So, if you wouldn't actually Yeah, looks like Maria Marie just joined us. Thank you. So Maria and I are kind of going to narrow or moderate this but, you know, we're obviously going to have input as well. And so the format is going to go, we're roughly going to be here for an hour. If we, if we could go that long, we could go much further.

But just to start off a few questions could, could you each like, tell me a little bit about yourself, and what you work on. And we could start probably. We'll start with Ben.

Hi, so I'm the floor program manager I've been in this role for about three years and basically my job is the chief chief cat herding officer. Basically, you're managing the federal release schedule and making sure we're actually sticking to it and gently encouraging people to come along and follow the processes.

I've been a member of the federal community for over 10 years. And I sort of tangentially participate in several other open source projects as well. I guess we'll go with Dan.

Hi, I'm Dan, I'm a software developer at SUSE, I work in the developer engagement program that I started out working on vagrant boxes then build few Visual Studio code extensions and sites that I also contribute to a few to a few open source projects I'm active in the

open SUSE community as a package maintainer and then I'm also quite active in the fedora community so I'm part of the i3 special interest group where we release the i3 spin of fedora I recently got elected into Fesco, the fedora engineering steering committee.

So, yeah, I have my feet also there. And Marie, if you want to, like, tell us a little bit about yourself and take over.

My name is Marie Norton. I am fedoras community action and impact coordinator. That is a community agreed upon name. It's very long. It means community manager support person. So I help with a lot of the administrative type things behind fedora but I also work on

community initiatives, and I work with a lot of the non coding teams, giving them guidance and support. And also work with mentored projects to be an IT so I do a whole bunch of stuff. I'm going to pick on that next Matthew next.

Okay, I'm Matthew Miller, I am the fedora project leader. That means I throw cats at Ben, I think that's the main responsibility. In seriousness, fedora is a community directed and community led project so it means that as a leader my job isn't

to tell the community where to go, but to help the community, find its collective direction and actually go there, because I think the nature of communities is to go in every direction at once, and that's not always the most effective way to get somewhere. It's an interesting search technique, but not, not the most efficient one. So, my job is to help us be more efficient, really.

Do I pick on the next person is that how we're doing this. Why, why not, why not. Neil, go.

All right then, lovely. So my name is Neil Gampa, I am someone who's all over open source stuff. Professionally, I am a senior DevOps engineer at Datto, working on software delivery stuff and release engineering type things.

But in the open source world, I am a longtime member of both the door and open SUSE communities, I've been a member of Fesco for a year now. But also I am a member of the open SUSE board since January.

And I do quite a lot in the Katie SIG and fedora, as well as the workstation working group cloud working group a number of other places, and I'm also in the open SUSE heroes team, helping build up infrastructure and setting up solutions to help support the open SUSE

community to do, you know, great things. And you work so much with Adrian you probably couldn't just pass it on to him. That's true. Hi, Adrian. Hi, Neil. I'm Adrian. I'm an open SUSE, I'm in first place responsible for the open build service.

Yeah, and then someone gets new ideas how to build distributions, like this, this a jump concept and I have to work on that. And apart from that, I take care about all the configurations from the non user distributions in the build service.

So and try to help out people. And in the old times, I actually was a project manager in the open SUSE project when it started. And before that, I was doing the KTE desktop at SUSE.

My daughter is messaging me that there's a large bug in the backyard and to come and save them. But I think this is one that she can probably handle herself. Sorry for the distraction. So it's not a panel blocking bug? Right?

Well, so, you know, we kind of have some listed questions that we we kind of came up with together. And I guess, you know, we've already talked a little bit about the background, but sort of one of the aspects of that was, you know, how what sort of cross collaboration do you have within the projects you're working with?

Anyone wants to take that? Feel free. Feel free to just answer. So we certainly have some tooling level cross collaboration where a really big example is the open QA service that we use that came from SUSE.

And it's really instrumental to Fedora's testing efforts at this point. And then we also have some key shared code, like the library that DNF uses to actually do its work comes from SUSE. And then, of course, we also have a lot of interest in shared upstream projects, which we work together.

I think that's the high level. Neil does all cross collaboration with all projects ever. And we've got Dan. So we've got actually some Venn diagram overlap of people as well, which is awesome. Yeah, and since you mentioned, since you mentioned libsolve, which is at the heart of libdnf.

Now, if I understood it correctly, nowadays, the micro opens with a micro OS, which is using transactional updates that in turn is now using libdnf. So it's interesting. Yeah. Earlier this year, Richard Brown and I switched open SUSE micro OS for desktops from using the

weird shell wrapper thingy calling zipper to using a libdnf plugin that implements the whole transactional updates mechanism.

So that package can even use it. And so GNOME software can actually do upgrades this way, as well as plasma discover and any of those other things like that. We also have micro DNF now able to do transactional updates with butter fest and things like that and there's some further development down the pipeline to enable it for cockpit as well.

And so that there's some there's some fun stuff going on with that and I'm hoping that we will have, you know, the DNF package manager with the transactional updates enablement actually used throughout micro OS on all flavors desktop server, whatever, because

it, it's actually worked out real nice and made for a much cleaner experience for integrating in the stack. Yeah, I think we also got some. We have some decent collaboration, the rust ecosystem, as far as I know the fedora rust special interest group was leveraging the open

build service, quite a lot I guess Adrian flinches now because I, I think it caused quite some strain on on the build service and a few at a few times, but there's been some some call up in there, as far as I'm

aware, I think there was a box at some resources they're not read and taking endless but yeah that's got solid. It gave Michael some heartburn, when, when we, when we started doing the dynamic build dependencies and OBS because the processes will get hung, it will just kind of stay there.

Keeping the VMs up, even after the builds were done. Because every time the every time you ran the build process. It starts up a brand new virtual machine and runs the whole build process inside of there, but because it didn't know that the diamond build dependencies cycle was complete.

It keep the VM running, doing nothing. So, I have a question about this at a higher level. Rust is an example but basically every, every language, especially every new language has its own package manager its own way of doing things. And as fedora we've struggled with what the best way to provide a good experience

for users, both developers who are using those languages and then consumers of those developers work. Like, in our, in our world and our traditional answer has been, you know, to cram all that through RPM with increasing automation, which is definitely cramming it all through RPM with one with automation is definitely one approach.

There might be other approaches to do that. So I guess on the Rust thing in specific. I think people see little value, it's hard, it's hard for us to convince the world of the value of putting Rust crates into RPM format.

Arguably, there's value, but it's a, it's an argument that we have to continually make if we want to say that. I think that there is almost zero value in both the fedora community doing it, and the OpenSUSE community doing it. So, how could we make it so that it is just one community doing that packaging.

We would have to sit down and, and essentially come up with a way how we want to do that. But there's also, there's also a limit to how far we should go, since we can't package the world anymore, at least

with Rust, with Node.js, these, these ecosystems they have really small standard libraries, and they have, they have huge dependency stacks. And at a certain point you really come down to, to think, does packaging everything as RPMs, does that really provide additional value.

It does, if you can, if you can, for instance, so what, there's been some recent development for the, in the build service to provide, to provide rendering of the dependencies, where you can

replace certain parts of them with, with RPMs that you ship, and certain parts that you take from upstream. And there you could say, okay, we have these core libraries where we provide support as a distribution or as an enterprise. And then, and the rest you can just grab from, from NPM or from, from crates IO.

Okay, that's three different problems from my point of view. I mean, you're right that, I mean, the build part is one problem, and we could

automate it or do it in RPMs or not RPMs. This is a fun discussion, but the other problem is if you do it not in, or not in a unified format, then you would need to deal with the cross-dependency between the RPM build and RubyGems and PythonPIP and so on.

So if you update my MySQL, it has an effect on all the other formats, and then you need to transfer this logic into, into the update tooling. So DNF, zipper, and so on, would need to learn about it. I mean, I think there's no wrong or right answer here. I think we can, should

work in all directions and evaluate. We can't know, can't limit people to use other formats. We can't force people to RPMs, but on the other side, there is still additional value, I completely agree. But what I think comes to the origin of the question, when working together with packages, no matter if

it's fast or whatever, I think there is really the big amount of our packages we could really maintain together. And I think our tooling is, is blocking us there at the moment because build service is so much different than Koji and whatever, a couple of whatever else you have.

And that's definitely an area where we should, I mean, we don't need to consolidate the build tooling, but we should maybe consolidate how we maintain sources in the first place. Yeah, and I think what's also blocking us is convention. So we have really, there's really different conventions between

OpenSUSE and Fedora in certain regards. So in Rust, it's relatively comparable since they have essentially the same heritage. But if you take a look at Python packaging, it works kind of differently. If you take a look at Go, I think that's

completely different. If you take a look at Ruby gems, it's also quite different, although OpenSUSE uses a fork version of gem to RPM. So I think to really, to really come to share our sources together, we'd have to all sit together at

one table and decide we are going to do it now this way and reduce the differences that we have. So we did this once before, about a decade ago, where we came together and reconsolidated the

way that our structures and guidelines in our packages were, I think was 2011 or something like that, where basically OpenSUSE and Fedora communities after like was a desktop summit or something like that,

where the guidelines were re-forked from Fedora to start over the guidelines in OpenSUSE, and things were built off from there. What I think failed after that effort was there was no ongoing communication between the two projects to solve problems together. So like something that when the Fedora Rust SIG was being assembled that Igor Reitz

and I did together was we made sure that the stakeholders from the different distributions that started the project together stayed in contact throughout the time that the stuff evolved. And that's something that we probably should be doing if we want to like make that successful this time around.

From a tooling perspective, I agree with Adrian that we don't necessarily need to be like, all right, Koji, OBS, smush, done. That's probably one, not going to happen, and two, very, very difficult. But, you know, we can do things like there's experiments going on with, you know, pulling the sources out

of OBS's version control system into a diskette style system with code.openSUSE.org, which is a Pager instance. Like we can start, and the OBS team has actually started working on SCM integration

with Forges, and they're working on Pager integration that could actually be used in this manner. So we could start leveraging some of the same conventions and, you know, blending a little bit of, you know, best practices to try to make this better and easier to share between the two projects.

One place that would make sense to me is the source get thing that some people in Fedora and Red Hat have been working on, which is basically maintain the version, the spec file stuff in an upstream repository rather than in diskette, you know, actual fork of the upstream source, and then use automation to go to diskette and then to build from there.

It seems like maybe it could be made so the same source get tree could then go to SUSE's get and build system from there, but using the same original source. That would be a huge win.

Yeah, I just want to correct a bit the things about continuous integration support at the moment. This is not. I mean, this has a different purpose, but we are working also on an alternative asset stores.

So the entire project even can be replaced with the get. So the next one, it can be other protocols can be used. So that would be the vehicle in our case. And yes, then we could exactly achieve this. And it doesn't matter if it's get or if we agree on anything else.

It's more important, I think, that we do the sources. Yeah, the source hosting together and what's for me, especially important, I think, is that we agree. How do we validate which sources we can trust? How do we trust upstream projects and so on? Because I see there the biggest value in our aggregation.

Build is, yeah, that's also something we need to deal with. But the really, really important and valuable work we do is collecting the trust. Actually, that brings to mind another thing, which is license identification in packages. I have no idea what you folks do in SUSE with that.

They're SPDX. OK, which is excellent because we are actually working on a project to possibly move Fedora to SPDX for our license tagging.

There's a lot of work to go there, but that means that we can audit everything. Yeah, I think that would help collaboration there as well. Yeah, and especially we could also leverage projects like Cable, which is a license.

That's a license checker module that runs in the OpenBuild service. And it essentially scans all the sources that you throw into a package and tries to find out all kinds of licenses. It's pretty good. It finds all kinds of interesting things.

About a year ago, I've packaged RStudio for OpenSUSE. And then through that, it came into Fedora and it found a lot of licenses that Upstream bundled and wasn't aware of. It also found a bunch of stuff that Upstream still thought they had bundled and didn't anymore for five years.

So what is that tool called? CAVIL. CAVIL. C-A-V-I-L. I think it's a license sticker. Oh yeah, license sticker was the old name.

So something that might be interesting would be if we could get CAVIL deployed in Fedora infrastructure and then wire up a bot to do it on Pager PRs. And we could also replace the thing that's done in Fedora review with using CAVIL and start using it that way.

And we could also share the license corpus that we use in Fedora and OpenSUSE. We discussed this in Dresden a little bit, Matthew. So Red Hat has a tool called PELC, which is used internally.

P-E-L-C. That is part of the RHEL process, and it's an internal tool, not a public tool. And we've had some talks about open sourcing this. I feel like SUSE does this and we could collaborate might be something we could move towards.

I saw Neil's face. There's a tool that exists that I've never heard of before? Yes. What language is it written in out of curiosity? It's been around for a long time, so my guess is Python, but there's a small chance of it being Perl, right?

I don't actually know. I haven't actually looked. CAVIL is Perl, so... We could merge all the Perl's. Excellent. Yeah, if merge all the Perl's is one thing, but then if it's Python, then we'll have to have a shootout and figure out which code base is less awful to work with.

The one that's not in Perl is the one that's less awful to work with. Come on! And I'm not even wearing my Perl shirt today, but I have one that I wear all the time. I love Perl, but... Matthew, I'm trying to be diplomatic here.

Perl is not too bad. It's really hard to transition, though, because we have a lot of other things we want to hit on. Oh yeah, sorry. I'm going to go to Ben here, and I'm going to read this because I couldn't break it up so easily.

But the messages, really, of collaborating amongst the projects really resonates. I think we see it as we talk about it. Ben, do you have any opinion about why that is, and what kind of message...

You just started off with Ben. Ben, yes. Ben said he would do it, so... You asked if I have an opinion, which is a funny question to ask. Yeah, you know, I think... Think about my own experience. I got started contributing to Fedora because I had been using it,

and here's this thing that I'm getting for free, and people are putting effort into doing, and I felt sort of an ethical obligation to give back to the community. I think that's true to some degree for a lot of people who participate in open source projects, and so the whole idea is that you're putting your code or your documentation

or your design or whatever out there for everyone else to also use, and so it's just sort of inherently collaborative, and because there's not these strict boundaries of, yeah, we have Fedora and OpenSUSE and Ubuntu and Debian and all these other distributions

that have some differences, but we're all using the Linux kernel. We're all using the same basic user land tools, so there's not this strict thing where I'm working in this one community, and I'm only going to work here because nothing touches.

As soon as you start working on anything that goes into a distribution, you're almost certainly impacting other distributions, and then it starts to make sense to work together. So, Dan, actually, I think you said you would probably also...

Yeah, I mean, I'm afraid Ben already said most of the important parts, and if you do open source, at least in my opinion, open source, or more or less, for me, open source is to a good extent about the community,

about the people. It's also about the code and that you can modify it, but it's also mostly about the people with whom you work with, and then it's about collaboration, and it's kind of wired into the heart of the whole thing.

You can put it out there into the public so that people can reuse it, and the whole thing started like that. So it's kind of baked into its genes. Okay. Well, okay, so the benefits...

I mean, you could see the benefits with collaborating. Actually, do any of you have any specific examples that you could think of? So I guess the earliest example really for me that I think really demonstrates this quite well

is when I started working on bringing up support for soft-float ARM architecture, so like the really crappy useless ARM architectures for DNF and RPM.

So that involved going to, at the DNF level, adding in the markers to identify to that, but also teaching libsolve how to do it, and going through to that, which meant touching to both a Red Hat project and an OpenSUSE project, and then going to OpenBuild service so that it would learn how to actually sort that

and be able to select the correct builders for that as well, and those sorts of things. When I was doing that architecture bring-up for a professional project, thankfully, nobody will ever see the light of day of it because it was a terrible thing,

and I don't ever really want to do that again. But because it was something that involved different distributions, different projects, I even found there was a Linux distribution that was actually shipping RPM-based distribution with DNF and all this stuff for ARMv5, and they were like,

yeah, if you can help us out with getting this all fully working with this new stack, that'd be great. And it's like, all right, sure. And they tested some of my patches and made sure that it worked. So with a little bit of Majya's help and Michael Schroeder's help in libsolve

and Adrian in OpenBuild service and Jaroslav Ronchek, I'm sorry I screwed up that name. I'm sure I messed that name up. In the DNF team, it went fairly well, and I was able to easily work with a whole bunch of people,

a whole bunch of random people to get something that was both simple and complicated at the same time actually done and usable. And no, ARMv5 is still a terrible architecture.

Right, yeah. I think another good example is also OpenQA, which was also previously mentioned. I mean, OpenQA is relied on by, I mean, that's the thing that makes OpenSUSE Tumbleweed roll and be actually pretty stable

for a rolling release distribution that releases up to five times a week if you compare that to other rolling release distros, which break, break, break, and break. We won't name names. No, we won't. But so it's, and a good chunk of that is achieved by OpenQA.

And then Fedora using it, you see especially Adam, you see especially Adam contributing to OpenQA, also upstream, and fixing stuff that sort of is used by Fedora.

And so I think that's one of the, that's a pretty good example. And Adam also added something unique to the OpenQA ecosystem that I found really handy. He wrote a Python client for OpenQA, so I didn't have to write a URL to interface with it.

Aha, you're not going to get away from that fight. We're going to come back to it. I figured I'd just point it out. Adam added something that actually made it much more usable for a broader set of people, and that helped me start poking at it and testing. Whenever I'm working with OpenQA stuff, like either in OpenSUSE or Fedora,

I use the Python OpenQA client so that I can automatically go find something, fetch it, and take a look at stuff because there's a lot of stuff in OpenQA, and navigating by hand is very, very annoying.

And if you want to, and if we want to go down this Python versus Perl route, OpenQA is now also adding a Python API. So in case you don't like Perl at all and don't want to use the test API, you will be able to use the Python-based test API soon.

But it looks exactly the same. I can expect Adam to port everything over to Python. I expect that will happen. Possible, but it looks the same, so. Sure, but it's the thought that counts. And then we'll rewrite it in Rust.

Okay, you're banned. It works, but if you have a common goal and those have advantages of it, then collaboration works mostly automatically in most cases. It's important to find the common goal and the common benefit. Yeah, that's I think been the hardest part in general,

was just finding a way to bring everyone to realize that there is a common goal because a lot of times people don't realize that, you know, they may be framing the problem differently in their head or they're thinking of it in different terms, but it's still like the same kind of thing and everyone's still, and sharing the workload, you know, many hands make light work

is, you know, an old phrase that is still true even today. Like collaborating makes it a lot easier for us to do bigger and bigger things together better. In doing the questions, we had one that a lot of you actually responded to

that you would want to answer and one was, and it kind of is opposite of what we're talking about, but collaboration can sometimes feel like a drag on innovation because of the required effort to communicate and synchronize with many different people.

So how do you overcome this feeling? Oh man, that one seems like it speaks to me in particular. The hard part really is trying to, the hard part about making the collaboration work is trying to,

not necessarily make it someone else's problem because that's a lot of what, sometimes that's what a lot of people kind of default to, but trying to find a way to have everyone see the benefit of solving the problem. And the reason I find it important to do that,

even though that it's pretty grungy and unrewarding work most of the time, is because the end result is I get more people that can help me solve the problem better because in a lot of cases, if I'm doing the thing by myself, I'm not a 10X engineer. I do not have the capability to make magic out of nothing.

I am not that good. And the only way I'm even halfway successful on anything that I'm doing is because I can get help from others who are willing to chip in and make it successful.

That's the real 10X engineer right there, the one who can convince 10X engineers to work with them, right? I still feel like a failure after drag.

So it may sound a little self-serving, but I think having somebody, you know, in that sort of act as like a project or program manager role, who their contribution is just managing some of the collaboration and the communication really helps. You know, Fedora didn't have somebody in my role originally,

and it was sort of a crazy disaster. Now it's just like slightly less crazy disaster. But I think, you know, that sort of the same principles apply when you get into smaller, even sort of more ad hoc collaboration is if there's not somebody sort of keeping the cats all going in the same direction,

you then do have to communicate with each person individually one-on-one, and that becomes an unmanageable overhead. I'm going to echo that for the community-based work as well.

People are hard. Oh, come on, Adrian. I think you kind of have the hardest job of all. You have to bake all the things work for everyone. Oh, no, no, no. I have to excuse that it's all content. All problems are on the content.

I'm never good. I don't know. I distinctly remember a couple of times where I have to go in and ask you, like, hey, this thing is not working because stuff's missing. What do?

My daughter has solved her insect problem by deciding to go to the mall with her friends. That's an interesting solution. Solution makes sense, honestly. I'm proud. Who among us has never said bugs are hard?

Let's go shopping, though. Fair. Yeah, but I think what really helps in terms of collaboration, if it feels like a drag, is to essentially consider if I push this stuff upstream,

yes, it's going to be more work in the short term, but in the long term, I get more eyes. I get more people to look at that. And so in the long term, solution is very likely going to be better. So that really, that really at least helps me because I know, I mean, sometimes you submit a pull request somewhere,

and then the discussion starts and it goes around in circles and weeks later, it's still not merged and at some point you get annoyed and you think, oh, I could just fork this thing and be done with it. And then the project lives for 10 years and you think, oh, dammit, I should have been maybe a bit more resilient

and actually go through with this pull request. So I think in the long term, usually collaborating tends out to work out positively for everyone.

I have a response to this. For myself personally, overcoming that feeling, it's a lot of adaptation and not being so like, don't hold on to your idea of what the outcome of this is going to be. Let it evolve and kind of accept that and release it.

How I go about it, at least with the non-coding teams within Fedora working amongst themselves. I'd probably say coding, programming, that's the easy part. That's the part that honestly does not matter very much, most of the time.

The actually getting people to sit in a room together and not throw pitchforks at each other. That is the hard part. Even sitting in the room. Oh my goodness, yes. Those are the things that really strain my desire to do this kind of stuff.

Because it's really difficult sometimes when you have really unfortunate personalities is the way I'm going to describe this. Really unfortunate personalities in the room. Whether it's code, whether it's documentation, whether it's design, whether it is advocacy or any of those things.

It really doesn't matter what space it is. Juggling personalities and trying to get people to mesh together is really the hard part. Because when that falls apart, that is what leads to forks.

That's what leads to split efforts. That's what leads to project failures and things like that. I noticed you said both forks and pitchforks. One of the things that's, I mean, some of its personalities and some of it is people who maybe need to learn to work better together in collaboration.

But a lot of it is, this is very personal for so many of us. And it's very hard to not take the smallest things very personally, very quickly.

Especially when it is something where you put in 100 hours a week, both your work time and your free time and whatever. It's been your life and your passion. And it's very easy for somebody's comment that they didn't mean a certain way that sounds dismissive to set you off.

Or for even things that started as technical to become very just adversarial. And so it is a hard thing to deal with. I'm just going to add that codes of conduct make collaboration easier. It's definitely something we implement in the community to make things easier for folks to work together.

And it's definitely helped. I don't know if codes of conduct in themselves help, but having a process to make that code of conduct work is, I think, probably more important because I have been involved in a ton of projects that have them.

Not naming any particular names, but they have code of conducts and things like that. But with no mechanism to make them real, to make them enforceable, they're just words on a digital paper. They don't mean anything. It's quite one thing to just say, you know, we're going to copy the contributor covenant or insert your favorite template of a code of conduct here.

It's quite another to say, I'm going to back this up with action when somebody actually points something out and says that this is a problem. And in a lot of open source projects, and a lot of communities, sometimes you just have one without the other.

And that's just, it doesn't work. It's not enough. You have to mean what you say and say what you mean. Can we lighten the mood a little bit more. And we'll, we'll talk about

like, so, you know, with with collaboration, what do you all think could be improved. I mean, I think we did on a few things already. For sure, but anything other things that come to mind. I think the advantage we have is our distributions are so large and we have so many individual pieces.

And in some cases, we won't be able to collaborate, although the additional time effort to agree on something would be way too much that it isn't worth it, basically. But you have so many packages that there are still definitely some stacks where we could aim for that we would be should be able to work together.

I don't know which one to pick first, but we, let's say, I don't know, something. Rust, if you want, if you want to use this example. Where we have the same pain and where we should, yeah.

Yeah, I looked at a little Rust project I have that all it does is it makes a little world with trees in it that you can move a little figure around this. It has 236 dependencies. So, am I ever going to package that up in the traditional manner, not if some unless somebody else agrees to package at least 234 of those dependencies.

I have written a extension for VS code and including development dependencies. It's over 1000 node models. Yeah, and I have been conservative. So, I'm not packaging those.

No JS makes me want to replace this water bottle with something way stronger. Yeah, but where I definitely see where we could collaborate, where we definitely, I think, can collaborate and should collaborate most, for instance, not only the packaging stuff but also image building, since that's that's something where essentially

essentially every distribution has its own tooling so in the open build service and for the open source of distribution, mostly use Kiwi. Fedora has, I think, Lorax is the tool.

There's nine different build tools. Okay, I wasn't aware that it was so many but essentially is already a pretty is a pretty powerful tool, and it would be great if we could just, if we could also work, work together on something there, since he we can build Fedora images for instance, it can build a bond to, and yeah.

Neelus Neelus doing his thing since he brought in a good. Now we have 10 different ways of doing it is what you're saying. I will aggressively make a 10th one.

aggressively rip out all the other ones if we replace it with Kiwi because I am so tired of fixing all of them every time I make a change to them. It's a massive time sink and it sucks and everybody should feel ashamed of how many times I had that this wheel has been spun over and over again.

With square wheels that are chipped at the edges, which sharp spikes on the sides. I think another way we can improve the collaboration is, you know, we think a lot of our

collaboration tends to focus on very technical things whether it's you know packages or how we're building the process. I don't know if we necessarily doing a very good job of collaborating on how we build our communities. But you know it's really interesting. You know I was right before the world shut down last year I was at the scale conference and I spent about an

hour in the open SUSE booth, talking to an ambassador there, and every problem that they said they had like that's very familiar. And then, you know, the, the open SUSE community survey. And it was back over the winter, maybe, you know, a lot of the problems as like, Oh, this is these are the exact same problems that we

face in Fedora, and I think it'd be great if we had a way to work together on those things too right because, like we said the code is not always the hard part. And I think there's a lot of benefit, you know, culturally it feels like our, our projects are very similar. We have a lot

of shared community members so I think we, you know, collaborating on the community parts is a big area that we haven't really tapped yet. I think an unintentional positive of pandemic COVID times has been a nice

chance for our communities to engage at a higher level at these virtual events. And, you know, NEST and the release party we've had, you know, different organizations come and hang out with Fedora, you know, and this cross collaboration panel is a great example of like something that maybe wouldn't necessarily happen just this way.

If COVID hadn't happened we hadn't put more time and energy into virtual events, and I think it's given a different swath of people a chance to connect with communities that are tangential.

So we've seen more engagement and more folks that are events, and I'm guessing that that is part of it. It's definitely not intentional. It's an observation. Yeah, but I'd like to ask again, if you have a shared community somewhere, then they need to have a shared goal.

Because then they can talk about the same thing but we would get this if we share some components, if we would have, for example, the same GNOME desktop. Then of course, if you speak about gnomes and it doesn't matter if it's user or Fedora. So it would be then, yeah, I don't know then he would maybe even need to come name something. I don't know.

Susan Dora. Dora is working on a community outreach revamp. And when that is is all set and done and has a bow on it, love to share that with other communities, they can adapt it.

We're planning a resource library, you know, it's happening. Yeah, like, this is something that I kind of ran on in my platform to become a board member was,

I personally have felt that the OpenSUSE community lacked a particular, I want to say empowerment to feel like they could communicate and collaborate and communicate and execute on things in a way where they felt like they could be seen, like, something that was a problem that I had observed, like, listening

in the OpenSUSE Discord server in the matrix rooms, talking to folks like pretty much everywhere outside of the OpenSUSE factory IRC channel. The common issue was, you know, I'm trying to figure out how to do something, but I can't figure out how to figure out how to do something.

And when I, even if I could figure out how to figure out how to do something. I don't know how to make people know that I did this thing and like maybe look at it or see if it could be made better and things like that and I feel like this is a problem that spoke to me so very hard.

And, and it's something that I'm hoping, you know, that, you know, with this closer ties between Fedora and OpenSUSE, we can learn a little bit from each other about how to do that sort of thing so that our community members can feel empowered to drive change,

excellence and growth in in both projects, like both Fedora and OpenSUSE, you know, deserve to be able to be successful and make, you know, the people that use these projects to live, to work, to play, to be happy with it.

Sounds good. Such a statement, Matthew. Neil, don't you think that this kind of a problem is because we have too many communication channels and they are, some of them are just too little?

So, at least with, with everything but IRC and the mailing lists, they're all bridged together and unified so when someone talks from one avenue, the other people, everyone in the other avenues actually can see each other and respond to each other.

So it feels a lot more connected than it would like say, for example, if you go into Fedora's matrix Discord or Telegram rooms, they're a lot more fragmented because there wasn't an intentional approach of connecting them all up front. Whereas when we were introducing the real time chats across the different platforms in OpenSUSE, a distinct goal was making sure they were all connected to each other.

It's generally not allowed to introduce a communications platform that is not connected to the other ones. And so if it's a real time chat platform where users and developers and other folks would be, you know, communicating with each other, there needs to be a way to connect them all so that nobody is missing from the conversation.

And that was something that I think alleviates a lot of that problem, at least on the OpenSUSE side. The main actual problem has been that we have not been able to connect IRC to all the rest of them because of a whole bunch of historical mess with how the IRC channels were managed.

With the unfortunate situation around IRC that has happened, it has been an opportunity to actually fix that too. So like one of the things that I'm hoping we can actually resolve soon is bringing everybody, you know, onto the same page so that, you know, someone who unfortunately is on IRC

can talk to everyone who's on Discord, Matrix, Telegram, and whatnot, and be able to do that sort of thing. But the second part of it is not just the real time chats, but like, people don't know how to get started to do something in a lot of cases, and I don't know the answer to that problem.

I don't know how to solve, how to help people like get started with their thing other than case by case things, and that doesn't scale. So, Neil, we've kind of, sort of, sort of solved this problem a little bit in Fedora with the Join SIG.

It's a, like a group of people, it's a chat room, and a repo. That's it, very, like, low commitment effort, and it's simply a place to send newcomers, and the folks that hang out in that chat room, help them open a ticket, like a little intro ticket, trying to like get some information out of them,

and they connect them with the group that makes sense. So, it's a big problem, we're solving it with people, and it's working pretty well. Okay, cool. Something to look into then.

I already heard it too. So it looks like we're sort of hitting that top of the hour, and I think we'll probably finish it up. Is there any last words that anyone would like to say? Famous last words?

I think Neil's soliloquy from a few minutes ago was an excellent ending point, so if you go back to edit this video, just stop it there. Chop it. And that, I think that says everything there is to say.

I was going to do a shameless plug. Everyone's invited to NEST 2021, and OpenSUSE will be there, so it should be a great time. And Adrian will give a great talk about OBS stuff and how they're supporting Fedora, building Fedora on it. I mean, should we do this panel at NEST?

I think it'd be fun, it'd be a different, it'd be a second audience. Call for participation, still open right now. Yes, it is open until July 16. Get your proposals in. Sure. But yeah, I'm really happy that we did this.

This is really nice, and it lets us show the perspectives from both of our communities. And hey, Adrian is here, which I barely ever see Adrian on anything, and that just excites me on a whole different level. It's not my time. It's quite late for me.

It's not against you. I know, our time zones do not align at all. All right, well, I want to thank you all, and enjoy the rest of the conference, and thank you for being here. Thank you. Thank you. Thanks for having us. Thank you. Thanks for having us.

Bye. Bye.