 Hi everyone, I'm Karolina. You may know me from some Fedora Contradictions. I've been a package maintainer of Python packages for over a year now I'm also a member of Python safe and collectively we take care of Over 700 packages in Fedora. I was checking it and I was really surprised by the number In my daily job, I work as a team member of Python maintenance team at Red Hat and most of my time I make sure that the New versions of Python packages are updated and nicely integrated into Fedora ecosystem. Okay Today's agenda is quite short. The presentation will not contain any funny images. So we don't have to look at it It's mostly for me to Know what I'm talking about So I'll talk briefly about the issues a new package maintainer in Fedora deals with Then I like to elaborate a bit why we consider full request workflow more beneficial Rather than pushing directly to the origin branches And how do we use are the crucial parts of crucial part of the workflow? Finally, I want to share our consensus Our team's consensus about how we'd like to do it and how you can do it too if you'd like So let's rewind back to the time when we all wanted to become a package maintainer in Fedora The typical path is that you create a new package and you submit a new package review request in Baxila Those of you who remember Remember also that the learning curve is quite steep. We've got excellent packaging guidelines But they are impossible to read and comprehend Just like that We also During the package review we can have some Need picks pointed out by the reviewers But once the package gets approved to Fedora, you're pretty much on your own If you don't have any co-maintenors or if your package doesn't belong to some very important package Stack like like all the fighting packages You can do really weird stuff with your package and no one really cares Especially if you push directly to the Rohit or Fedora branches And in reality, it takes weeks and maybe months to actually grasp what the packaging is about It was mentioned yesterday at Nest that you know packaging is not about creating an RPM. It's about integrating and If you Do really weird stuff with your package and your package becomes a part of bigger stuff like the Python stack It can happen that someone from Someone doing for example master build will take a look at it and help you with it furthermore Later on but that otherwise not really The other thing that's very typical to fedora land, but not only is the amount of tribal knowledge and There is a lot of it a lot of undocumented stuff that just goes without saying which is harmful towards new contributors They will always fall into each trap that's They're waiting for them and by falling into the traps they create their understanding of the domain So in the end, it's not that bad So my point of view in this talk is a person who's created their first package around a year and a half ago and I'm I started reviewing other people's pull requests around a half a year later I want to share my view on pull request reviews as a mean to create to use those two sources that we have the packaging guidelines and the tribal knowledge and Create a unified stream of knowledge, which you can use to help your understanding Yes Okay Pull request workflow. So first why do as a Python main? Actually use it in Fedora. We take care of plenty of packages. So we want to keep track of what's going on in them That's for one Another thing is that you get the benefit of CI. This is really good thing basically Instantly when you open a CI the COGIS scratch build is run and it will give you the green stamp that your packages Can build that's really helpful because as you know, we have Two commands for pushing one command for pushing the check for committing the changes and the another one to update the sources and it's very typical that you forget to run a third package g new sources Another CI that we have available in Fedora. This kit is Zool And it does a lot of checks for you. It can check that your package installs fine It runs tests it runs RPM this inspects and and much more So if you don't use Zool on your CI start using it. The opt-in is very easy. It's trivial. You have to add two lines of Code to a YAML config file. It's it's really nothing We as a team have an idea how we want to integrate our packages into Fedora It is an ecosystem So a new update can break other packages, which leads to long devil discussions Untugging the builds broken row height broken stable Fedora's in the worst case Apologies and stuff So from this point of view, it makes sense to be reasonably sure that your changes don't bring this kind of impact also Back to my point of view. I do believe that pull request workflow is beneficial to newbies to the newcomers For one when I as a newcomer Unexpressed package are submit a pull request to a package Anyone from the Fedora land can come see comment on my changes and propose better and they will propose better, you know, it's No, no question was left unanswered for from those I had in our this get On the other hand as a pull request reviewer If you're a new member you can learn ways and quirks the experienced packages have you can basically mimic What do they do and then use it for your own contributions? I believe that Reviews can help creating a mental model of the packaging for the new members You can you have an open channel with the experienced packages Just right there where your knowledge gap is So basically you can ask for special specific lines even and get some explanation Also, your question may actually help identify the gaps in the process and documentation as I said plenty of things come without saying and Maybe some of those things are really worth documenting so you can establish that maybe the comment message is not so clear or maybe You should update the documentation packaging guidelines in some other so the new commerce perspective is really valuable So basically what you get from lurking at other people's contributions is to get better ideas how to perform Particular actions in your own contributions So let's rewind again. Let's let's come back to this new commerce stuff So your knowledge is somewhere here you just managed to get your first package to Fedora and then Okay How am I supposed to review changes to I don't know macro ecosystem or I don't really know what the fight in my Metadata are so they are changing half of the ecosystem or they are dealing with some C extensions or multiple architectures like How am I even supposed I don't understand how the changes I barely can read the spec file. I can't review it, right and How can anyone how can anyone expect me to? so The solution is that's just another piece of tribal knowledge the experienced package maintainers They do the reviews and they somehow know how know how to do it. So we as a team created a guide We decided that it's it's beneficial for everyone to pull some of the tribal knowledge from the team members and We did it from the point of view of a person who does know basics of git But maybe have never actually cooperated in an open source project with the guide Which is an open document anyone can read. I will not read it here Don't worry There is a few sections which quite Extensively cover The basics and not so much basics We cover for example the committing standard how to deal with white space noise You know when you open the spec file for the first time in your very smart IDE and Save the spec file. It will just trim all the white spaces all around and people will not be grateful for that It also covers How to write proper explanations how to test your changes if you're a pull request submitter You can prepare your pool pool requests your changes in a matter that will be well Welcome by the other contributors to Fedora. Also, if you are a reviewer We included a long and short version What you could do or what you should do The long version is intended to read and understand and then you can use the short version just the bullet points To copy paste to your Fedora full request So even as a newcomer even as a person who doesn't have like extensive knowledge of the packaging world you can check a lot of stuff and you can Actually help the full request submitter even if they are very experienced To make their submission better For example, you can check the CI you can check whether the commit is understandable whether the commit scope is sane, whether the right Buxilla ticket is linked, whether the right discussion thread was linked and so on you can check You can think about whether the change should go to older Fedora's or just the raw height or whether the change was tested enough so there is a lot of thing that you can you can basically lean on the guidelines and use them as a guide as a path towards even more complex contributions, so if you when you already If you're already familiar with the long version, then you have the short version the checklist. It's 11 bullet points To use any time And if anything is unclear, you can always ask the submitter or ask another person to Help you with the review. It's not like If you touched the full request, you have to stick with it till the end and this is only your sole responsibility It doesn't work like that fortunately for everyone Also our guide contains Quite a lot of instruction Dedicated instruction how to perform copper impact checks As a team we grow to we grew to use copper as our testing environment quite a lot the folks were talking about it just in the Python master build talk. I recommend to to lurk at their talk here at NEST And We've Documented how we do it how we want to do it so you can if you have a package if you maintain or comment in Package set that has the potential to break the Fedora ecosystem It's really good to adapt it and to use it Detailed instructions how we do it in the Python world are there so After a few months we had a discussion in our team like are even people using the guy So as you can expect the answer is not even in our team. No One of the arguments was that 11 bullet points It's like overkill for trivial rebases when you just change the version and change lock in the In the spec file Well, my answer to that would be I guess you have to wait it for yourself. I Use it. I use the the 3d checklist Every time because it helps me organize my thoughts and even if I evaluated at 7 out of 11 Are not applicable. I actually spared a second to think what's the impact of the poor request to the fedora ecosystem and Of course in our team There are some very experienced folks whose tribal knowledge was the one that we pulled to create the guidelines So I kind of expect that they don't need to be reminded to add the back seal our reference to the change lock or so Yes, you know, they are and Yeah, from our discussion, we also realized that the copper impact check template is really used by the folks they report They like it a lot and it became officially the way you want to test an integrate our changes to Fedora and Me personally I would be half of the package or I am if I wasn't lurking at other people's contribution It was really hard for me to start with the reviewing but with the guide I felt empowered enough to Actually be there and you know invest time and energy Which helped me a lot in my journey. So it's time to head to the conclusion So let me just underline some points. I think Are the most important in this poor request workflow? And There is one minus right you have to wait Like when you open pull requests and wait for someone to review it can last a long time and it can for some inpatient People it can be quite hard, but on the other hand the package maintainers really benefit from pull requests from the green sea ice stamp that everything is okay to Getting access direct access to others people knowledge just right where they need it the beginners can pull the knowledge out of the experienced people and Maintainers or co-maintenors of their package, which is great way to onboard people And like give them opportunity to learn Fedora is more stable and the chance to break it is reduced when you have another pair of eyes that looks at your changes There is a big potential to reduce the dogs and the process gaps Not not to reduce the dogs dogs. I'm sorry to make the dogs more complete and to reduce the process gaps So that it becomes more approachable and complete for the newcomers and Also in the long run from seeing more of the ecosystem than just your own contributions when you read a lot of other people are Improving in the for the rightful system In the long run you get the potential for making the packaging world better. You are much better equipped to propose better changes Well meant changes like better convenience macros or better processes at all So I think it's a win-win-win situation Thank you very much for your attention. That was it and I Let me take a look at the chat. I was not following it. There are no questions You can ask the questions now if you'd like. I'll just scroll a bit Yes, all of this works if you have some other people in your package probably a good tip would be also to Watch the packages you like and just watch the activity there So you can get notified through the email when something happens on them So so Miro said that the good tip is to add six to your packages to get a bigger chance for a review Of course, you can always You can always ask for the help Using Fedora channels like Fedora devil mailing list or on IRC How to be better to fix big dependency issues. Well, that's a philosophical one Can you be more specific in that? Yeah, I was right. It's always easier to prevent them than to fix them We use copper a lot. We build all the dependent packages We check the build logs. We ensure that we don't Pride the other packages intentionally Unfortunately, if the packages don't contain tests, for example tests, it sometimes is the effort is smooth but Even in the new packaging fighting packaging guidelines, it said that check must not be Totally raised from the spec file. So hopefully it's getting better Okay. Okay. Thank you very much one more time for attention I will now stop sharing the screen, which probably will cost my browser to fail