to introduce the speaker.
Thank you.
Hi, folks. Good afternoon. Welcome to the evening sessions.
I'm going to turn it over to our next speaker, Franzy, to
introduce his set. Just a couple of housekeeping rules if you
could make sure phones, et cetera, are on silent. When you're
taking a seat, they can be loud. Make sure that you do them
gently and try and keep the talking to a minimum. Thank you.
Hello, everyone. I'm Franzy Szek. I'm a product owner of the
packet project. I will use this project as an example during
the talk. Thanks, everyone, for coming. And I would like to
also view things from you so don't sneak out with the doors
behind. When I was thinking about this talk, I was thinking
that if people come here, they already maybe had issues like
me and already were thinking about it. So let's use their
ideas as well and don't just talk for half of an hour and let
them show and share. So I would like you to connect to this
URL or just use menti.com and use this number to just connect
to the slides so you can also provide some feedback for me or
others. I hope it will not break the Wi-Fi or disappear or
something, so we'll see how it goes. And this is an example
question. Thank you for putting the answers there. That's not
only to test it, but also so we know what are you coming from
or what are the, what is your background? So let's give you a
couple of more seconds. Wow, so many, so many. Okay. Yeah, and
also a positive thing is that if you don't see the slides
correctly, you can watch them on the screen and, yeah, sorry
those who wanted to just fix some bugs in the meantime or check
the next session so you need to use the phone or laptop for this.
So sorry about that. Okay, so we'll move on. In the title, there
was two times mentioned stream, but what do I mean by that?
And it's what I mean by that is a stream of code or the program
that comes from up, from the developers, down, down, down to
the users. So that's the stream I have in mind. And you can have
various pieces on the way and anything what goes up to the
developer is an upstream. What goes down to the user is downstream.
So for example, Fedora is a downstream when looking from the
developer point of view or from GitHub, GitHub, but it can be
also an upstream for CentoStream for rel. CentoStream is a downstream
of Fedora but upstream of rel. So depends always from what
place we are looking from. For this talk, when I mentioned upstream,
I mean a Gitforge development, the GitHub, GitLab. By downstream,
I mean some Linux distribution, for example Fedora in my case. I
tried to use upstream developers and downstream maintainers to make it
really clear, but just so you know. So just to check, try to show
others where do you belong? Are you more a maintainer downstream guy
or are you more an upstream developer, maybe curious how you can
get to the distribution. So let's show others how we stand here
and what I'm talking to. So mostly maintainers and if you are both upstream
developer and downstream maintainer, you are somehow in the middle.
Okay, so it's not moving much, so I'll continue. Okay, so let's
back to the package project I mentioned in the title slide. Something
around five years ago with few people around. We were thinking that
we will create a new project and as a goal, we said, hey, let's make
upstream and downstream closer together. So let's provide some downstream
feedback to the development and also for downstream maintainers, let's
provide them some connection to the upstream. For example, when they
release new code in upstream, so let's get it automatically to downstream.
And it was like, yeah, that will be awesome, everyone will be happy.
So we started work on that and few months ago, yeah, we came to the
upstream developers and said, yeah, we have this federal integration for
your project and it's really easy and you will have like new functionality
for your project and can be sure that your code will run.
The feedback wasn't so positive and we were really surprised because, yeah,
we are trying to help you. So what do you think why developers might care
about downstream? Why they might even bother why they shouldn't just live
on GitHub, GitHub website and live their awesome life and don't care about
any distribution at all. So, yeah, hard question. I hope you are typing.
Yeah, availability, software option. Wow, wow, so, for me, articles, okay, yeah,
many, many reasons. Yeah, without distribution, they might have no users.
Yeah, a lot of obvious things. Just to note, after the session, I'll share
the results with you so maybe I'll also set up some blog posts but you will
have it attached and, yeah, wow, so many things. It looks like it makes sense
to care about downstream. So just a couple more seconds. Yeah, people,
shitty tools, yeah, revenue maybe also. Yeah, sometimes there is a middleman
that you don't need to tackle the video users. Sometimes you just don't want
users maybe. Okay, so let's move on. So, we asked maintenance.
Hey, maintenance, we have this nice service for you that will automatically
send your upstream releases to your service. Always. We were very positive
that we helped people. I don't care if they produce new code. It's definitely
a new box and more work for me. So, I'm not sure if I want this service.
So, same question. Why do you think maintenance should care about upstream?
Why there should not be just the upstream that don't produce anything and I can
happily leave just rebuild my package every half a year or so when there is a
new version of the Linux distribution and live in peace. Yeah, users want new
releases, yeah. New features that's related. Missing updates. Similar stuff,
similar stuff. Yeah, bug fixes. Yeah. Writing the code is hard and I really
don't want to do that and all the patching, yeah. Can you be a maintenance
upstim? Looks like not, but yeah, there are a lot of maintenance with dead
upstream. But availability, security fixes, stability. So, yeah, we have at
least 17 reasons why to do that. So, I think it makes sense to care about
upstream. Yeah, if there is no upstream project, then there is no downstream
project. So, that makes sense. Okay. So, we really wanted to help people and
it was quite a surprise that we were honest on that and that was our goal to
bring upstream and downstream closer together. There was nothing hidden, just
a really clear goal to help people. So, on the way, after these feedbacks, we
also get some positive ones and also there were people that were both upstream
and downstream and after all we get some users and also users that provided some
feedback and after like these, somehow 40 years, I can say that we are saving
some time people and helping them and there are also great people that uses
our project. So, it looks like it makes some sense. But it wasn't easy and we are
not done definitely and we've collected various feedback and complaints on the
way. So, let's pick few typical sentences that we've heard during those years
and let's take a look what we can do to help in those situations. So, the first one,
when things go wrong, I don't want to look into the logs. I don't understand the
downstream logs. There is some build failure and I don't understand it. So, what
would you do in this situation? You are providing a build system integration or
maybe like you are running RPM builds for the upstream pull requests or testing
on Ubuntu or anything like that. Just the downstream feedback for any upstream
change and people don't want to tackle with the downstream logs. What, when things
go wrong? What would you do? How to help with that? Yeah, reliable mechanism for
filling bugs. Yeah, definitely. If the problem is like a packaging problem,
anything else what we can do? Okay, so it would be transparent. So, if we need to
give the logs, so let's let them suffer as well. Yes, I should have 20 relevant logs
to find the one relevant. Yeah, so help with some home combing those. Cool logging libraries.
I'm still missing some crucial. Yeah, you can snap or flat peg, yes. But you can get
like a failure from creating the snap. So, it's, we can treat like snap or flat peg like
this and another distribution maybe if either of the ends but still. Yeah. Okay, I hope
that's my job. Okay, I'm still missing one crucial. Like the obvious one. You know that
is not possible. Probably that's why the response is not here. So, better logs. Yeah, it's usually
not so easily possible. Sometimes yes, sometimes we can do something about it but with these
systems, if you've been on the talk like the Dant had an hour ago about all the federal
systems we had in place, yeah, we are trying to integrate with all of them and you, for
example, copper had multiple logs and all the systems have different logs. So, and they
use more or other tools. So, this is layered and we don't have power on all the logs. But
maybe we can, as someone mentioned correctly, we can be good in the aggregation or some
visualization or we can use AI. Okay, just kidding but a few colleagues and me are actually
working on something like that. They are trying to collect various logs with the failures and
trying to get like human input what's going on here and how to fix that. So, if you are
interested in that, check this out. I really hope this will happen and will produce some
really nice data set that can help us to provide some really nice way how to not tackle with
hundreds of lines of logs that I don't need to tackle. So, that's just in the beginning but
I'm really looking forward to that. Next thing would help us is provide nice notifications
and also connect by that, I mean connect people that can help. And it relates also to the last point
that we need to set really clear expectations. Who is responsible for what? Who should take a look?
Yes, sometimes it's not clear, sometimes it can be really valid back in the code that is
sketched quite soon and that's really nice but sometimes it can be downstream issue and
sometimes it's something in the middle and so it's really nice when we are introducing these
two to make clear expectations. Who will, which like maybe also time-based and with the notifications
we can maybe ping people that can help. Okay, so just a single distribution. Why can't you support
all of them? So, what would you do? Yeah, there are people from various distributions so that's
maybe common that if you want to introduce some CI or anything that, yeah, but if I enable this
for Fedora, I want also the BN, SUSE and everything. Can we help somehow? What would you do? Yeah, we can
use build systems that support multiple targets like copper or OBS and these. Yeah, snap, flatback, yeah,
we can like switch the distribution but when we discuss in the very beginning, we might want to
care still in those distributions that we maybe work on. Yes, some distributions, yeah, a lot of
distributions are really, really different and it's hard to somehow compare or maybe some obstruction. Yeah,
I'm lost in all the good suggestions. I'll read them probably later. So, yeah, it's probably not
possible, definitely not all. There are a lot of distributions but as someone suggested, we can maybe try, maybe
we can also have open source that someone can contribute, maybe some architecture that can maybe combine
various backends so we can maybe share. If you have an open source, so for example, then we'll come from SUSE
and say, hey, let's support impact it also OBS and we can maybe collaborate so that's also possible. The tricky one
is we are used to do distro specific terms and we need to be really careful about those because when we mention
various scratch builds and patches, metadata, bugs, and all the weird terminology, it might be really, it also might be a
reason why they are scared and developers don't want to hear about those. So, describe those terms and be careful
and also you can hide those somehow so we don't need to speak about co-properties but we can maybe mention RPM builds and these things.
So, yeah, what helps us is also we are supporting various functionality types and what helps is to provide easy and reliable testing
like infrastructure or so if they can rely on that and they can run their test code or run their tests on this reliable infrastructure
we are using for example testing bar project for that so we don't need to do that ourselves. And easy on boarding, I'll probably mention that
multiple times but it's crucial because if they hid like the very first problem during the way and yeah with those distribution things
it's not easy and we've spoiled it multiple times but it's important. Yes, sorry, I don't want to have more files in the repository.
So, CI system that's generated maybe for any upstream CI so yet another config file. Don't be lazy, yeah.
Yeah, there are thousands of files in the repository and you don't like yet another one or next to. Yeah.
A few interesting things. Anything interesting? You see, okay, so yeah, we can put more complaints. Yeah, yeah.
Very interesting things. Yes, I'll probably move on and read those later. It's interesting but so yeah, we might want to stick with the one line if possible, one file if possible
because if it is possible but still better one file than multiple files and also not sure why but people rather put a shell script into the JSON or YAML instead of providing a shell script
and specify a name of this shell script in the YAML file so we can help them do that. Yeah, if there is more content we can maybe let them link it.
We can also enable some custom locations, custom name of or some sub directory so they can maybe hide it a bit and also for example Zoo project uses global configuration
if people really don't want to put anything to their git repository just provide a separate git repository they can create a pull request and enable this.
It's tricky from the developer point of view like how to do that, how all the messaging should work but yeah. Yeah, I have my own automation works well.
So, I have my script or anything and I'm happy with it.
How to live?
Yeah.
Yeah.
Use on Civo. Yeah.
Okay. Good for you.
Yeah, standard protocols.
I'll move on.
So, this is a generic when we want someone to start using something else even like with the comparable tools we need some killer feature.
We don't, having just the same feature set is not enough. They need to have clear motivation to have something extra when they move.
Easy onboarding. I've mentioned that this is crucial. We are for example trying to do some online workshop with the gutter platform and various funny stuff to help them.
Also, and that can be the killer feature if things break. The people or the users does not need to take a look and fix that and then that can save a lot of time.
So, with the maintenance of this automation and we can save them a lot of time and we need to clearly communicate this but we need to also do that.
So, if things break we should take a look and just ignore it.
And work on the right things. So, listen to the community, listen to the people and try to like don't just assume that you are doing the right features but just ask and get something there.
Yeah, your automation can break some rules for example packaging rules. How do you tackle these things?
And yes, sometimes when those packaging guidelines were created the automation wasn't such a thing or maybe when they have written that they expected that humans will interact with the packages and maybe standardization,
who's rules, yeah. Yeah, we can also tweak the rules. It's not set in stone so we can maybe discuss. Yeah.
I trust the both modern and human. Yeah, that's a positive thing on the automation that yeah, it usually does not do like the human like things and be kind and that's I really like.
So yeah, be open for suggestion, communicate, don't ignore the issues. Just talk and see what others think about that because sometimes it can be like really valuable feedback and maybe people already have a suggestion how to fix that or how you should behave.
Yeah, sometimes you can also let the user decide for example we've talked about an issue if we should upload some archives to the cache if we should do that before it's merged into federal this gate and we were not sure we someone wants the automation someone.
Yeah, someone wants just the security so let them decide. Yeah, and for us it helped that we are trying as much as possible to have the provisions as a regular user so we are not kind of special in any way with one slide exception to get less permissions that we need but otherwise we are trying.
Yeah, so.
Similar to the previous one. You can continue with the voting but I'll skip to two points I had.
Yeah, when people think that they you behave differently we can provide some config options but usually bait.
There can maybe be maybe people will realize that they don't need it but maybe they will be a new user that will have similar config option or similar feature request so you can maybe combine it for us.
For us user defined actions helped a lot because we've done everyone has a different workflow and it was really hard to do securely and well but this was for us a huge and other.
Yeah, and respond to the first issue and questions crucial even if it is like a little you weeks thingy that you are showing how you how you treat your users.
So that's all from me. This is the project page for Stornon account and if we have maybe two minutes for question if you have any but maybe you can ask the audience.
We don't have. Okay, so sorry about that but I think you've shared your opinion on that. So thanks a lot everyone.
Thank you.