How to change anything: openSUSE is what you make it
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 55 | |
| Author | ||
| Contributors | ||
| License | 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. | |
| Identifiers | 10.5446/54540 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201812 / 55
8
9
11
15
17
19
20
21
26
28
30
31
32
34
38
39
42
44
45
47
51
52
54
00:00
QuicksortBitSlide ruleComputer animation
00:33
Open sourceDistribution (mathematics)Classical physicsEnterprise architectureQuicksortBitSystem callDistribution (mathematics)Computer animation
01:15
Cubic graphSlide ruleSoftware developerFundamental theorem of algebraOpen sourceOpen setComputer animation
01:59
SoftwareSoftware developerSoftwareFamilyPerspective (visual)QuicksortSphereCASE <Informatik>Distribution (mathematics)Group actionComputer animation
02:42
SoftwareService (economics)Multiplication signInternet service providerCodeIntegrated development environmentPower (physics)QuicksortDecision theoryMathematicsLecture/ConferenceComputer animation
03:50
Open sourceLine (geometry)QuicksortMereologyCore dumpComputer animation
04:37
Group actionOpen sourceDecision theoryStandard deviationLoginWhiteboardDistribution (mathematics)Default (computer science)Core dumpFLOPSSlide ruleNumberRule of inferenceOpen set1 (number)Streaming mediaConnectivity (graph theory)Endliche ModelltheorieHTTP cookieElectronic mailing listOpen sourceMereologyEmailStructural loadMultiplication signPhysical systemDefault (computer science)Distribution (mathematics)Video gameFrame problemCausalityProduct (business)CASE <Informatik>Different (Kate Ryan album)Division (mathematics)Fitness functionMathematicsQuicksortModule (mathematics)CodeSoftwareStandard deviationSoftware maintenancePower (physics)Data managementComputer animationLecture/Conference
08:59
Maxima and minimaDecision theoryAxiom of choiceDeadlockDecision theoryDifferent (Kate Ryan album)Product (business)Presentation of a groupDistribution (mathematics)CASE <Informatik>QuicksortGame controllerData managementBitEndliche ModelltheorieRevision controlSet (mathematics)Group actionCurvePoint (geometry)Multiplication signAxiom of choiceDeadlockComputer animation
11:33
Conflict (process)Decision theoryWhiteboardSoftware developerTerm (mathematics)WhiteboardIntegrated development environmentDecision theoryQuicksortWavePoint (geometry)Revision controlParameter (computer programming)View (database)Electronic mailing listEmailOpen sourceReal numberPosition operatorOrder (biology)Touch typing1 (number)RobotBitGroup actionAbsolute valueSlide ruleComputer animation
14:59
Online chatTelecommunicationElectronic mailing listPrice indexGoogolDependent and independent variablesFeedbackDirection (geometry)CodeLevel (video gaming)FamilySlide ruleDifferent (Kate Ryan album)View (database)Open setPoint (geometry)Computer-assisted translationIntegrated development environmentMultiplication signFeedbackElectronic mailing listEmailFactory (trading post)Context awarenessThread (computing)Distribution (mathematics)PlastikkarteData conversionDependent and independent variablesOnline helpBitQuicksortSelf-organizationFigurate numberWikiPerspective (visual)Goodness of fitStatisticsFreewareTouch typingOpen sourceComputer animation
21:52
Independence (probability theory)Open sourceStaff (military)System programmingCodeSuSE LINUXEnterprise architectureService (economics)Complete metric spaceChainProcess (computing)Open setBuildingDefault (computer science)Different (Kate Ryan album)Product (business)Open sourcePeer-to-peerCubic graphProduct (business)Different (Kate Ryan album)Physical systemSoftware repositoryDistribution (mathematics)Independence (probability theory)Default (computer science)CodeProcess (computing)Direction (geometry)Open setSoftware developerMereologyGame controllerConnectivity (graph theory)1 (number)Electronic mailing listDivergenceNumberEqualiser (mathematics)Arithmetic meanSoftware testingBuildingHeat transferCASE <Informatik>Suite (music)BitSlide ruleCodecMultiplication signFreewareQuicksortModul <Datentyp>Computer animation
25:31
TelecommunicationMultiplication signSoftware developerPoint (geometry)Configuration spaceProgramming languageMereologySource codeExtension (kinesiology)DampingMathematicsComputer programmingComputer animation
26:56
Module (mathematics)Service (economics)Open setBuildingSoftware repositoryCodeRepository (publishing)ImplementationRepository (publishing)TelecommunicationOpen setModule (mathematics)BitMusical ensembleInstallation artSlide ruleComputer configurationOnline helpFactory (trading post)MathematicsRevision controlComputing platformNumbering schemeRule of inferenceCodeUser interfaceSoftware testingSoftware developerFeedbackLink (knot theory)Staff (military)Functional (mathematics)Software bugService (economics)Logic gateForestImage resolutionFront and back endsPerfect groupDirection (geometry)Computer animation
32:38
FeedbackLimit (category theory)Software bugLimit (category theory)Musical ensembleElectronic mailing listState of matterMathematicsIntegrated development environmentMultiplication signTime zoneEmailCodecTelecommunicationData managementOnline helpCASE <Informatik>MereologyView (database)Link (knot theory)Slide ruleFeedbackOpen sourceQuicksortLatent heatComputer animation
38:07
Limit (category theory)VideoconferencingComputer animation
Transcript: English(auto-generated)
00:06
Okay, then. Thank you all for coming. I'm Richard. This is Jerry. We're both from SUSE's future technology team. I'm also OpenSUSE chairman. So, I guess I felt that was nicer to write on this slide. But, yeah. And, yeah, we're here to talk about sort of
00:22
how to change anything in the OpenSUSE project, how you can get involved and kind of give a bit of a sort of the philosophy behind contributing in OpenSUSE. So, obviously, we're at the OpenSUSE conference. We all know where we came from. We had the keynote this morning. You know, originally started as an open project promoting the use of Linux
00:42
everywhere. And, yeah, started 2015. So, you know, we're not old. We're classic. And a little bit hippy. Especially these days where, yeah, like Wojtek explained in the call this morning, the session this morning, OpenSUSE really has this sort of
01:03
whatever SUSE is doing on the enterprise side of things. Which means when I start talking about OpenSUSE now, I used to just talk about OpenSUSE the distribution. But if you look at the OpenSUSE project today, it's a project made out of many, many, many projects. In fact, this slide is woefully out of date. And I can sneak peek that tomorrow it will be
01:24
even more out of date because there will be something else to add to this slide. And the question then becomes, like, how did we end up with this complicated mess? You know, or mess. Arrangement. You know, you've got all these different projects. How did that happen? How did the projects get involved in OpenSUSE?
01:42
What is OpenSUSE when you've got all this stuff underneath it? And really at the heart of that, at the beginning of all of that, there is kind of one of these fundamental truths of open source, which is equally true if not more true in many other places. That, you know, every contribution, every developer,
02:02
every person involved in OpenSUSE is there because they've got some itch to scratch. They know what they want to fix. They generally have an idea on how they want to fix it. And so the thing with OpenSUSE is really a case of we want OpenSUSE to be a project where we can get them involved. We can capture them into our sphere of influence.
02:23
So, you know, they can help what we're interested in as a collective group. And, yeah, ultimately thinking it from a sort of broader project perspective, as we have this whole diverse family of software in our distribution, you know, when something does go wrong, when something doesn't get fixed, you know,
02:43
ultimately, you know, if a volunteer doesn't fix it, you're gonna have to find somebody. And that can be a pain. You know, you don't want to have broken things lurking around your project's codebase for a long time. So, you know, projects must provide value and time rewards or value of time for its contributions, everything that's coming to these contributions.
03:08
And as a volunteer community, you know, it's important to realize where that sort of decision making power comes from, whether, you know, who should be deciding what needs to be done.
03:21
The best person to decide anything, in my opinion, is the person doing that thing, the volunteer involved in that. The role of the project isn't there to tell people what they need to do. The role of an OpenSUSE project should be to give them the tools and the environment to be able to do that, to really empower them so they can get on and change
03:41
what they want to change in that project. And even if you did try to tell them what you wanted them to do, quite often contributors are like donkeys. They're stubborn. They won't do it anyway. So why does so many Open Source projects try? You know, we used to in OpenSUSE,
04:01
we don't anymore. We generally don't try and force people to go and work on these features. We just try and show the situation as it is and hope people come in and get involved and fix things. So new contributors should be able to pretty much start from day one as a walking, talking part of the project. You know, they should know what they're going to get involved,
04:25
get started and be able to go straight from birth to being an active contributor in the project. So how do we do that in OpenSUSE? You've heard it, in fact, I've seen at least one talk where this was already mentioned. You know, those that do decide. The core principle
04:41
of how contribution works in OpenSUSE. If you're doing something in OpenSUSE, you decide what gets done in OpenSUSE. And, yeah, that's, yeah, rule number one. We really should be talking about that far more often. But what does it mean in practice? My slide is showing here now. Sorry. Yeah. Well, like I said, it works best when the
05:09
team does what you need to do. That doesn't mean doing everything on your own. Team work helps. You need to spread that load across more than one person. You don't want to have
05:21
a situation where one person gets sick or one person leaves the project and an entire part of your project falls apart. But how those, therefore, you want to pull people together into teams, but how those teams work, again, isn't a cookie cutter model. If you think of something like OpenSUSE where we're dealing with many different up streams and many different components in the project, all of these have different requirements. Up streams
05:43
release things at different paces. Python works a different way than Ruby does and how they release all their modules and the like. So, how those teams inside OpenSUSE that are dealing with that should have the freedom to decide how to organize themselves, how to release their software. And it shouldn't all just be kind of forced into one unified messy
06:04
funnel of, you know, you must work in this way. But you do need to have some common standards, you know. And that's one thing we do a really huge amount inside OpenSUSE. But implementing that is generally done by consensus. Anybody can contribute to OpenQA
06:21
to decide the release criteria for what we release via OpenQA. Anybody can contribute to what we do in OBS. Even our spec cleaning tools, they're all open source, they're all open source. And then those few senior people acting as gatekeepers are just there to act as
06:43
gatekeepers enforcing the criteria that the community as a collective have already decided. So, there's no kind of grand overarching overlord. You know, we collectively come up with the rules and then these poor guys volunteer to make sure we stick to them. So, that means anybody can contribute to OpenSUSE right around day one. No requesting
07:04
permission. No asking for sort of, you know, maintainership of a certain package. Anybody can log into OBS. They can get an account. They can immediately start working on our codebase. And that means when it comes to sort of who's in charge of OpenSUSE,
07:24
it's your contributions that really do the talking. You know, automatic OBS checks, make sure things work, keep on working and, you know, sort of functionally testing. So, the question when it comes to, you know, do we accept this change isn't a case of, you know, does this fit with our product division or does this fit with, you know, SUSE's goals,
07:43
which we'll talk about more later. It's really a case of, you know, will this thing work? Will this thing cause more of a headache down the road? Which is a way easier frame of mind to be approaching random contributions from a broad community. And because we have that mindset, we don't fall into this trap that many other projects have of having steering
08:04
committees, engineering councils, product managers, project managers, benevolent dictators for life. All of that is unnecessary in OpenSUSE. And I think that is an incredibly good thing. It makes us incredibly agile and incredibly flexible. And it avoids problems like certain
08:22
distributions had with things like System D. If you look at examples like Debian, System D did not have an easy time getting itself into Debian. There was lots of people who wanted it. There was lots of people who didn't. Flame Wars erupted. And yet in OpenSUSE, we were the first distribution to actually adopt System D and nobody really argued with it.
08:43
Because a contributor did all the work or contributors did all of the work. It was there. It was merged. It worked. It worked well enough that we made it the default eventually. You know, peace, happiness, mostly. I mean, okay, the occasional mailing list because some people still don't like it. But it's hard to argue with the fact that it's there
09:02
and it's working. And that means OpenSUSE is an incredibly agile project these days. We can adopt new technologies, new ideas, whatever the crazy thing you want to work on incredibly quickly. And yet we're also flexible to kind of not do anything in one standard consistent
09:21
pace or one standard consistent way of doing things. In Tumbleweed, for example, there are cases where we are the fastest distribution on the planet. And there's other cases in Tumbleweed where we're significantly behind the curve because that's the pace that our contributors have decided they want to run Tumbleweed at. And that's what makes sense because that upstream is a little bit too crazy and their latest version is a little
09:42
bit too broken and therefore it's best for Tumbleweed to be that little bit further behind. Which ultimately means we have a better distribution to give to our users at the end. And, yeah. As I've already said, there's sort of no restrictions on finding an innovative solution. Sometimes there have been stuff done in OpenSUSE which if we had strict criteria, if we had
10:04
strict sort of project management or product controls, you wouldn't do it that way. But it makes sense for our contributors. It works. So we accept it. And it works. And they maintain it and tool. Yeah. And tool that. But it's not all perfect. It does have
10:20
some challenges with this mindset. Freedom does cause sort of a paralysis of choice. You can do anything in OpenSUSE. So what do you do? And, yeah, that does, especially new volunteers, does sometimes scare them away. That is one of the reasons why I'm doing this presentation to kind of show that it's not that scary. It's not that intimidating. You can
10:42
just pick any one thing you want to work on. It does sometimes also have a habit of misconceptions as established contributors kind of get seen as guys who know everything and they're making all the decisions. And, you know, it's not true. Really not true. I have no idea what I'm doing most of the time. And, yeah, it's important to realize
11:03
that you can just come to OpenSUSE with a brand new idea. You can rock the boat. Please do. It keeps us honest and makes things more interesting. We really need that to keep the project moving forward. But then there is, of course, at some point, what do you
11:20
do when one contributor or one group of contributors has a different idea that is fundamentally incompatible with a different set of contributors? Deadlock is a real risk in this model. And so you need to have what I refer to here as some kind of organizational checksum. Because, you know, you don't want developers fighting in the street. And in
11:45
the past, we've and in other projects, there's a tendency to I'm skipping ahead a slide. Conflicts happen. Sorry. Volunteers are human. Mostly. We do have a couple of bots in OpenSUSE that people think are human and keep on replying to emails from. But generally speaking
12:03
are volunteers are human. They have different ideas. And sometimes compromises can be incredibly hard to find. And when those conflicts happen between developers, there's a real strong tendency in OpenSUSE projects to see them as technical discussions or technical decisions.
12:23
And you see, you know, this is where I think so many mailing list flamewalls start in so many different projects. Debating the technical minutia of this way is better versus that way. And this is right and this is wrong. The OpenSUSE view, or at least the OpenSUSE board's view on this, this isn't a technical problem. If you have competing
12:43
ideas and competing arguments to the point where you can't find a way of getting along in your project, it's not a technical issue. It's a human one. You have people who are disagreeing and you need to deal with the people. Not the technical bit. It doesn't matter which technical solution is best in the open source world. More often
13:03
than not, in fact, the best technical solutions don't win. It's the motivated ones. Because they're the ones that have the contributions behind it. They're the ones that are going to keep on developing six months or a year from now. So who cares which is technically the best one? It really matters which one has the people behind it and which one can
13:21
you get the most motivation behind it. So it needs a human touch. You need to listen to all sides involved. They need to realize they're heard and you need to look at it from a very much an interpersonal and sort of emotional one, not a technical one. Sometimes ultimately even looking at all of that, sometimes a decision has to be made.
13:44
Sometimes things get so split that you do have to make a final decision on a topic. And ultimately that's a really awkward position to be in. Because at some point you're basically meaning someone's going to be told what they have to do. And it's an absolute
14:02
last resort. But in OpenSUSE, we have a group of volunteers who are responsible for being that last resort. And if you have a problem, no one else can help. Who do you call? The A team. Or seriously, the OpenSUSE board. And that's the main role the OpenSUSE board
14:24
plays in the project. As that escalation point, when those things get stuck, you can contact broader OpenSUSE.org. We'll step in. We'll try and help out. We'll try and smooth the waves and sort out that interpersonal problem. If we can't, we'll be the horrible people making the final decision so everybody can blame us and no one else.
14:48
The environment's there. Anybody can contribute to OpenSUSE. But how do you get started? How do you sort of get involved and, yeah, actually in bare terms do stuff? And this
15:00
is surprisingly nontechnical on purpose, these next slides. I didn't want to go into great detail about putting stuff into OBS or putting stuff into OpenQA. Because we have this broad family of different projects. This is the high level view of regardless of which project. My advice on how to get involved in an OpenSUSE project. And to reflect
15:23
that, I won't let this slide stay up there too long. But when this is all uploaded, we have a bunch of different mailing lists. We have a bunch of different IRC channels. That's the best way of getting in touch initially with our contributors, with our projects, with those teams. The list is even longer. Obviously. That's why I've listed like
15:42
lists, openSUSE.org and all of our free channels. Those teams do all scatter around there. But it's nice to know this is generally speaking, most of the project is mailing list and IRC centric with a good chunk of GitHub these days as well. Which I realized I forgot to put on there. The starting point is really doing your homework. Figuring out what
16:05
do you want to do. Understand what your problem is. The topic you want to fix. Whatever it is. Don't make assumptions. Don't read the register and other news articles and think those journalists know what they're talking about. Really figure out the problem from your perspective of what needs to be fixed in OpenSUSE. So, you know, do your research.
16:26
Have a look at the OpenSUSE Wiki. Have a look at the Arch Wiki. Have a look at anyone else's projects. What is the rest of the open source world doing? And figure out how you want to see that implemented in OpenSUSE. And start at this point the discussion.
16:43
This is why we're at OpenSUSE conference. I've been doing this already this morning. Bounce these ideas off other people. Start just getting a feel for what other people think about what you're thinking of. What you want to change. And, yeah, really get a sort of strong base of knowledge that you have understood the problem that you're
17:02
trying to fix. And then carry on doing a little bit more of homework. You know, have some rough plan for how you want to fix it. You know, what do you want the end goal to look like? You don't have to have all of the details. In fact, the details will change anyway when you start implementing it. But have a rough idea of what you want
17:23
the final outcome to be and where you want the project to look when you're done. The idea is this is the bit you really need to start when you start explaining it to other people. How are you going to get more people involved to work with you on this crazy plan?
17:43
That is if you want anybody to help you. If you think you know what you're doing, you figured out your plan, you don't need anybody to help you, then just do it. There's no like I said, no permission required. Everything is already open. Just contribute. But if you do need help, then you need to share it with the project.
18:02
And so, at least for the distributions, the best place for that is okay. Okay. Fine. Anyway. Yeah. If you're working on the distributions, the best place for that is the open SUSE factory mailing list and present your idea, present the plan, present your couple of
18:26
paragraphs of homework from everything you've been thinking about. And avoid presenting it as an open question. Don't ask what do you think of this, because you will get 500 answers. And none of them will be helpful. Most of them will be negative. Present it
18:44
from the point of view of this is what I'm going to do. And this is how I intend to do it. Because if you do it that way, then it's now the community's responsibility to stop you. And as confrontational as that may sound, it actually ends up really focusing
19:04
that feedback so you're going to get decent constructive or more useful feedback of why you shouldn't do things that way and how you should be doing it differently. And I've seen time and time again when that approach has been taken, the conversations are far
19:21
more helpful and the final conclusions are exactly what the project needs. Maybe not what was originally discussed, but exactly what the project really needs to solve that problem. So, you need to listen to that feedback. You need to consider that feedback. You don't necessarily need to do everything that feedback says. We are a smart bunch
19:42
of people. That doesn't necessarily mean we're always right. And, yeah, if you listen to all of that feedback and you're still sure that your way of doing things is how you want to do it, well, then, good luck to you. Go ahead. We'll see how it works when it's in the distributions. But if you do decide at this point that, okay,
20:00
I was wrong, it's not a failure to just admit at that point and stop what you're doing. In fact, there's enough threads on Factory that if people go back and think about that in the context of this, you can see plenty of examples where I've suggested stuff on Factory and then it never happened because people were right when they said I was wrong. It's a learning experience. And that's a good thing.
20:25
But if you are getting that feedback, the fast feedback really helps. Don't just post on the mailing list, fire and forget and ignore all the replies. Do respond. Do engage. Because those discussions are how you find volunteers to help you with that. There's been plenty of times in OpenSUSE where I've proposed an idea. People have argued
20:44
about it. Said I was crazy. Said I was nuts. And then I ended up with a team of five people, half of them who thought I was nuts, working on the thing with me. Because they wanted to make sure it was right. So, that's how you really that's how these self organized teams start more often than not.
21:02
Decide what you want to do. And do it. It's really that simple. And sometimes from these discussions and this way you do end up with multiple solutions to a problem. And that's not necessarily a bad thing. If you look at OpenSUSE, how many desktop environments
21:22
do we have? This is how we ended up with that. There's more than one way to skin a cat. Why not do all of them if you have people behind it pushing for it? And so, that's it. Do it. You're all set. Get started. Get cracking. Do whatever you want to do in OpenSUSE. It's an open project. Opens in the name. The clue is there.
21:46
And normally at this point I end up with people asking me, well, yeah, but what about those corporate guys? You know, what about SUSE? Aren't they controlling what you guys are doing? Aren't they deciding what needs to be done? And, okay, this is like I know
22:03
the third talk about this kind of today because I didn't realize everybody else was talking on this topic. But, yeah, you know, OpenSUSE is truly an independent open source project. Yes, it's sponsored by SUSE. SUSE are backing us. SUSE are paying for a lot of this this weekend. But not the only sponsor. We have others like IP exchange, B1
22:23
systems who are here as well. And applied micro. But SUSE believes in open source the same way OpenSUSE believes in open source. SUSE's contributions to OpenSUSE are done as peers, not as controllers in any way. And, you know, engineers are encouraged to spend less free time in here. I mean, you
22:42
know, just as a raise of hands, how many SUSE engineers are in the room? Yeah. See? Yeah. So, you know, you all know how it works. Yeah. So, there are plenty of examples like we hear. Leap 15 launch day. Leap 15 is based on
23:03
SLE. It's a wonderful example of how the two different communities in essence work together, work on the same code base. Tumbleweed is the base for SLE engineering. But all of that close working together doesn't mean that OpenSUSE's direction is controlled by SUSE. There are an equal
23:22
number of examples where OpenSUSE diverges from SUSE. For example, actually, I'm skipping ahead of a slide again. My slide bits are completely messed up. Sorry. We're all using the same tools. And in fact, like you heard this morning in the keynote, a lot of the things like CI, like
23:44
OpenQA, like a lot of the building you see in SUSE now all started in OpenSUSE. So, it's not just a case of code contributions flowing. It's also a case of philosophy and engineering processes and design which transfers from OpenSUSE to SUSE when SUSE realized that's the
24:02
better way of building this stuff. That's the better way of testing this stuff. So, it really is a two way street. OpenSUSE gets our wonderful code base for Leap. SUSE gets their wonderful code base for SLE. We share everything in between. But it doesn't mean we do everything exactly the same way. Like I said, an equal number
24:22
of cases where OpenSUSE diverges away. This list is getting longer and longer, in fact. But the obvious ones, the default desktop in OpenSUSE is KDE. SLE doesn't even have KDE anymore. We have a completely different style of the distribution when it comes to the product. SLE is lean, modular. Everything is these
24:42
different components the customers can pick and choose depending on how they want. And we distribute Leap as one large distribution in one large repo. Because that's the way we think is best to do it. And we have a completely different installation workflow. In fact, we have a completely different installation workflow in like every different product that we have in OpenSUSE.
25:04
And to kind of, yeah, give the sort of more visual example of how that all works. That's why Jiri is here. He works on the YaaS team. The YaaS team are perhaps the most SUSE controlled part of OpenSUSE. Almost all the developers are entirely
25:21
employed by SUSE. And they're working on SUSE products. But it's entirely open and, yeah, how it all works. Over to you now. Thank you, sir. Thank you, Richard. So, let me talk about how we develop
25:40
YaaS. So, first of all, what is YaaS? YaaS stands for yet another setup tool. I joined the company more than 16 years ago. And when I joined the company, the installation and
26:04
configuration tool of at that point of time SUSE Linux was called YaaS. So, nothing changed. It was completely home grown. Home developed solution. Project started in SUSE from scratch. Developed by a team which was completely
26:26
part of SUSE here in Prague and in Nuremberg. And to some extent this is how it is until today. Of course, back then, all the development was in house. We wrote it in proprietary
26:41
programming language. Even though we got the source code, not all parts were under a free license. All the communication was inside the company. Which is something that has changed nowadays. All the communication channels are public hosted by
27:01
open SUSE. The repository is public. So, we do our work way more in open. Even though the team is inside SUSE, it still allows you to contribute. There are really many options. I
27:24
put just three of them here on the slides. YaaS consists of modules which are more or less independent. So, if you are brave enough, you can write your own new module. Does anybody have any idea of module which was written by
27:44
community member who was not and I think never employee of SUSE? There was one called one click installer. Yeah, it was developed by Benji Weber. And there is one more example
28:05
which was the GTK backend for user interface. It was also written by somebody out of SUSE or at least out of the ASTM here. I do not know whom exactly. Well, writing your own module might be a bit too much for the beginning. So,
28:23
you may start fixing your own fixing your favorite bug which bothers you most. Or maybe you are lacking some functionality. So, this is what you can do. So, how do you provide your code? As Richard mentioned, all the code
28:43
lives in the open build service. Here on the slide, I put the link to the development project where all packages which go to open SUSE factory are hosted. So, if you so, this is where any package will end up. Of
29:04
course, this is for open SUSE factory. If you want to provide a package for any older release, they have their own subproject. Anyway, yeah. Most of the teams do not work only on build service because it has no
29:23
conflict resolution. And the data team benefit of version control systems like, well, 16 years ago it was CVS for Yast. And then subversion nowadays it is Git. And, yeah.
29:42
Yast lives in the GitHub repository. So, how to contribute properly? Here I put on the slide the link to the Yast project on GitHub which hosts all Yast repositories. So, the easiest way and I have I can see at
30:07
least two members of the Yast team in the room. They can confirm that this is the way we appreciate most is find the repository where you want to add new stuff. Fork the
30:20
repository. Work on your fork. And when you think that you are ready to be merged to our code, then create a pull request. The reason for pull request is not something like we do not trust you to give you access to the repository directly. This is how we work on our own as well. It has various advantages. One of the
30:43
rules we have in the team is that all code before it gets merged should be reviewed by at least one other developer. And the pull request scheme which is provided by GitHub, it serves this purpose perfectly. Anybody who can
31:02
comment on your changes, give you feedback, you can discuss it in GitHub. Then later if the one who gave you the initial feedback goes on vacation, anybody else can step in. Has all the history. So, it's a nice platform for the communication based communication for the code
31:22
changes. And we also have various tools hooked into the pull request which means, for example, you can see before you merge your changes whether the package will build after your change is merged. You can see that you
31:43
got the test coverage of the package into half if you did more changes. So, all these checks can be done before your code is merged. And it prevents submitting package which is anyhow wrong. So, after the discussion about your code
32:08
and if it's your first submission, probably there will be some. You get the package merged into the Git repository and as long as we are working on factory, the automation behind will take care that the package appears
32:23
in the development project and later the submit request to factory is created. Of course, or maybe not of course, but you might need some help when you implement
32:41
your change. The best way to get help, of course, is to ask. The team communicates almost exclusively on public mailing list or in public IRC channel. Here you have the links on the slide. So, whatever is more convenient for
33:07
you, whatever you prefer, either send us a mail or connect to the IRC channel and ask. Just keep in mind one thing, especially if you live on the other end of the planet, the
33:21
team is located only in two time zones next to each other. So, Australia is not the best time to ask on IRC. So, you
33:40
created a pull request and nothing happened. Well, of course, it doesn't put us into the best light. But it can happen. It happens for request of the team members too. So, the only thing you can do and you should do is contact
34:02
us and remind us about your changes. And if you do it in the right time, then I'm pretty sure that somebody from the team will give you the feedback which you are searching for. Important, but I think that's true for all open source project. Do not take any feedback you might get personally.
34:24
Nobody from the team is native English speaker. We come from different environments. So, whatever. If something sounds okay for somebody, somebody else may take it personally. We never mean it. What we want to do is really to find a way
34:44
to get your changes to state in which they can be merged. And really get them to the project. So, if you want to
35:03
help with Yast and are you searching for what could I do? Yes, there is definitely a lot of work which you could do. If you do not have your favorite bug which bothers you or you don't feel that you are able to fix it, we the Yast
35:27
team has so many bugs that to be honest to ourselves, they cannot be fixed in a reasonable time by the team itself. That's why we try to identify bugs which in our view seem to be
35:45
easy enough so that anybody who does not have that much experience can fix them. And we put them on a specific assignee in Bugzilla. So, if you would like to get inspiration what to start with, this is a recommendation where you find
36:04
bugs which we believe that you will be able to fix. So, want to learn more? I put on the slide two links to the
36:21
Yast documentation. They should give you a hint what to start, what to learn, how to start. Anyway, have you ever seen a documentation which is perfect? Yeah, nobody did. And
36:41
if you look into it, find something missing. Again, please tell us. If you do not tell us what is missing in the documentation, you can be sure that we will not fix it because for us it seems obvious. And until somebody who is not familiar with the topic reviews, it will remain in our
37:04
review this way. So, just sort of in closing, you know, you decide whatever
37:21
happens. There's nobody else. It's up to you entirely what the project looks like. Not a single part of the project is off limits to contribution. We have even had cases like tumbleweed is a fun example. For years the tumbleweed release manager was, in essence, a community contributor. Well,
37:40
was a community contributor. Didn't have anything to do with Sousa until Sousa hired him. The project is here to help. And have a lot of fun. Does anybody have any questions? Comments? Feedback? Shouting? No? Okay. Thank you. Thank you very much. Thank you.