 So, welcome to the Fossum 2017 Distributions Debron. I am here with Anne Nicola and Samuel Versheld, and they are going to talk to us today about magia, successes and lessons learned after six years of forking, or six years after forking. Okay. Can you hear me? Can you hear me? No. Okay. So I have to speak loud. Okay. So, I'm the girl, yeah. I'm here for the quota, and so we are going to speak about magia. Who knows about magia here, except the usual suspects. Okay. Thank you. So, we wanted to propose a talk about what we have done in magia and how it caused since we started in six years ago, in fact. So, a brief presentation of magia for those who don't know about it. So, magia is a fork from Mount River in 2010, when things went bad in Mount River, and we didn't want to lose 10 years of work on code. So, as most of the salaries were leaving the companies, we decided then to just to save the code and create this fork. It was a decision in about five minutes, and we are a bit mad, but after all, it was a good decision. So, what we wanted to preserve is the free software basis, and the way how it's easy to use for both contributors and users, because you will see that it's a big goal for us to make it easy for people to contribute to magia. Also, we had a big challenge as the distribution was based on a company before, and we have to switch to a community, which is also a big thing to achieve, both legal, financial, organization, and so on. Just to give you an idea about magia community, we have about 100 packages of codes. They are not all active a lot, but still they are working on magia. We do have 3,000 bugs here, also it's not all active, but it shows quite an activity on bug management, and we achieved more than 20,000 bugs just some days ago. We achieved. We achieved, yeah. Most are fixed. Yeah, most are fixed. Well, we do have some mailing list also, for example, one dedicated to development with 2,050 people registered, general discussions, and also quite active for rather for users, and a lot of discussion there, and still some issues to make those people speak together both on one side developer and in the other side users. Well, what we wanted to do was to especially give back the control to the community, because Montreal was part of the distribution before, and we had to make an all community project. We had to set up all the things to make it work, and it took a long time at the beginning. It took about nearly four months, four months, especially for the older infrastructure tools, because we had no specific idea how to handle it at the beginning. So it must be reliable, maintainable, scalable, and so people started to work on something we didn't have in Mound River, like config management tools, like puppets who administrate all the infrastructure, and also find the resources, like the servers, the money for the bandwidth, and so on. So the first version of the distribution was not a big one. It was just to start from Mound River and then go to Magia. So the first big work was to bootstrap the distribution. I don't know if you know about it, we have a blog post about it. It's just to rebuild all the distribution from the very basis so that we have all from Magia, and we are sure that we have everything we need as packages and codes to rebuild the distribution. And when we started, we didn't have any goal, just to save the code. That was the only goal we had. And finally, the goal just went after. This is how we are organized. We wanted to do something clear and easy to understand for newcomer. So this is the team we communicate. So we have, in fact, two big structures. You have the Magia Council and the Board. The Board is reserved for all the legal aspect for the Magia Association. It's based in France. Really, nearly nothing happened in the Board because it's just to manage this legal aspect. Everything happened in the Magia Community Council. This is a place where all the teams in the distribution have some representatives. And we have discussion between the teams, between packages, documentation, communication, and so on. And we try to find solutions there. We have regular meetings. During the release, we do have one meeting per week on IRC. Otherwise, it's every two or three weeks. For now, for six years, we had to report some problems maybe one or twice to the Board only. So this is working quite well for now. And all the teams then have specific goals. So as I said, packages, documentation, development, security, and so on. And they are all organized as they want. They are quite autonomous. We try not to be too heavy. And just ask them to report to the Council so that we can have a global view of what is happening in the distribution. So people, for now, as you will see, we try to lower the barrier to entry those teams so that everybody can contribute in Magia. Yeah, autocorrect congratulations slide. We are happy for now. Because if you follow a bit Magia, we have now five releases out. So this is quite nice because fork is always a big question. Is it going to work? Is it going to end the time? And well, we have five distribution out. The six end on the way. It's taking time, but it's going. And we do have now a real community of users and contributors. That was the big fact. Are we going to keep our contributors? And it's working at the moment. What we are proud of is we didn't have nasty issues on these five releases. Means no big headline with Magia, Brock, everything and so on. So upgrade is going smoothly and new version are going smoothly also. The only thing which has changed at the beginning wanted to communicate on planning say the next version is planned for this date and things like that. And we are taking the, I could say the Debian way of freezing as a big one. We release when it's ready because of the constraint of the community. Everybody is not available at the same time. We had to make some choice and decide to just to lower the headlines. She's among us to the one who's coming from the company before and now doing it all on her free time. And I started like many contributors as a user who started reporting bugs and progressively get into the distribution and contributed. So I talk about contribution. So some fights, obvious fights, a healthy community project needs to renew its contributors base or even if possible grow it in order to do better things. So we need to attract potential contributors and most of all hasn't stayed. So how it works in Magyria, it's that our team are welcoming. That's not just a word. It's the way it works maybe in something's better than in other teams, but globally there's a good relationship between people within all contributors or new contributors. And we have a special attention to newcomers because we know it's not easy to go somewhere. You don't know people, you don't know how to contribute. We try to make it easy. So in Magyria, it's not just for elite joining the teams. It's for anyone with strong motivation and of course being able to work together with teams with other people. And we have a mentoring program to help them start in good conditions and learn how we work together. The barrier to contributing is usually higher in users' heads than it is in reality because there's a common belief that you need extraordinary skills to contribute to such a big project. And some users have the habit of thinking that they are outside and that maybe some remaining client mentalities that the providers, the users, the consumers. So we have to communicate and invite them. So I try to illustrate that with extraordinary schematics. So on the left, that's what's in many users' heads, not every one of them, of course. So you have the contributors and that's what they will call Magyria. And you have the users and that's not Magyria. And the contributors that deliver the product and users that use it and they ask when they have problems or need something and there's a distance between them. And I think it's a big distance. What it's actually, it's that by definition Magyria is the community of all users, contributors all together because just using the product, just using Magyria is already contributing. It's enlarging our user base and it always brings some kind of benefits to the distribution in the end. Maybe someone will see what you are using and get interested into it. Maybe you will be so angry at a given bug that you will take the steps to repel the bug and so you are already contributing. And the steps to go to a next level of contribution, if you wish, quite low, quite easy to, small, yes, small. So now I could talk a lot about contribution but I will focus on a specific part of contribution that is important in any project but in community distribution it's a real question. It's about leadership. So we have lots of different projects, lots of different teams in the distribution, lots of people. We need some kind of coordination so we need some kind of leadership to some people to show the way and to act as catalysts to provide more guided work. So we have elected team leaders. In some teams it's not just one, it's several co-leaders who work together and there are also deputies and almost I looked at our current teams and currently almost all of them just started as users and went progressively into teams and became team leaders and not every team leader dreamt of being a team leader. Sometimes it and maybe often it's no one else who wants to have this burden on their shoulder and someone says okay I'll do it. Also that's another form of leadership that is with less responsibilities but with great impact if done it's helping other people to work together towards some goal and I will take an example. Lots of text that's if you don't understand you can't understand me you have all of it but I'll try to to be clear. So we have this annoying release blocker bug. It's been there for months. It was in magia6 and the process was okay it had been triaged correctly assigned to the right person of group of persons but nothing happened so you are annoyed by the bug and you decide that you will try to have it fixed. You don't know how, you don't know who will manage to fix it but you try and first you say is there is this bug? Is someone working on it? Can someone work on it? You can't give orders and it doesn't work at first probably everyone is too busy or thinks it's someone else's job someone else has the skills to do it. So you ask again still no success so finally you try your relations and you ask to someone specifically you know that might be the right person and he says okay so that's hope but in some situations this stops here actually and the bug is fixed and everybody is happy but in this slide since I wanted really a lot of text I'm continuing so several weeks a month again later you notice that it's still not solved so you decide to act again that's that's the act of leadership you decide to act you're not a team leader you're just someone who wants things to move forward so you ask about the status but the first volunteer finally won't be able to make it in time or maybe won't answer at all so you're back to square one no one wants to take responsibility alone for these difficult tasks so you try something else you ask several people who are annoyed by the bug also let's fix it together and you form a commando and you work off-list with them exchange information about it and you focus during a small lap of time on this book and finally it works someone gives an element of debugging someone else knows something about how system d works and will tell you a possible thing to try and one week later it's fixed so that's an example that shows that there's a formal contribution that is not easily described in teams or in much of teams of kind of contribution but is also really important to make to remove the blocking points and it doesn't require extra generous skills just communication and commitment you have to to want it to be fixed okay yeah that was the longest slide I know so now we'll talk about our qa and security teams so both used to be inside the company before the fork so we had a consent because we didn't know if we would find volunteers we could not just take the former contributors and transpose them into the community because there were no former contributors so we had to breathe something from scratch it worked the qa team who test the updates candidates and also the iso image iso images before they are released well we were lucky to find a great team leader who shaped the team with great communication and this team now and for years has had weekly meetings on IRC and it helps them feel like a crew that chat about anything it's a real team and and although that team leader had to stop recently the team is strong enough to continue they have an efficient monitoring program if the team where we send new contributors when they don't know what to what to work on we tell them try the qa team and it can be a step trust packaging or other contribution forms too okay and they have their own tools so that it's easier to contribute so it's really effective now and the security team it's one person so that's one extremely dedicated person who watches and creates bug reports for every security issue and tries to get other packages to work on it but ends up doing most of the work himself surprisingly even this way we are often as fast as other distrusts who have more resources and we have a high confidence in these updates thanks to the qa testing so it works so far but it's not sustainable in the long term but there's hope a new package will join the security team five minutes four minutes for you okay so what's now like we are not going to switch to her but we have many goals still to achieve and i will talk about it on the tool side it's not to to speak about tools because there are tools but they can help on achieving these goals so we try to to start very simple very easy and give the tools to work to our contributors but that was six years ago now wow long time we do have now resources this is really reliable sorry even more than in montreva because when I was working in montreva we did have some more crashes like in than in magia and we do have also a small motivated team on the ciz admin tools and they are they are very high level skill so that's a good thing but this is far from being perfect why because we do have we still have some oldish side in our infrastructure especially for example we still have some svm use we have packages in svm and all the code is in git so we still have to migrate all the things to git this is a big goal to achieve also we do have to adapt the tool we have the more the the the most user friendly tool we have for now is git web wow that's not not too bad but we do have to think about adding new tools like you know like git lab for example to help people contributing also we have a big bottleneck in season in season admin tool team sorry because for now either you have all the rights on all the infrastructure or you have no rights there is no granular rights so it's hard to integrate the team because you need to trust them a lot because you are just giving the root password in fact so that's a big also that that's a big evolution to make and also we we do have also a point with the patches management tool for for now if you want to contribute and just send a patch to start with you have to use either the mailing list or on ioc and the best is plexia but it must be lost because there is it's a hard thing each time so we do have also to find a way to to to help people to bring some patches as a first contribution so what we have as a goal is using today tools nowadays tools and as i talk we are thinking about introducing git lab just to enforce our workflow and help people like with review tools for example patch review tools inside and give some more easier access to the code and to the packages this is a big thing to do also we do have a lot of tools upstream tools for magia like building the isos all the drastics tools and and so on and we do need to give some visibility to this project so git lab will be a way to help us to advertise and take some more contributor on it and finally yes we have to also help people to rethink the workflow we use git but we use it as svm so no branches so it's hard to collaborate because everything basically is in master so if you want to contribute you have to you have to create branch which are not used for now so it's very hard to to manage so at least well if you if you if you want to to speak with us just we need some some feedback we have some questions here which are still handling we are we have some questions about packages organization maybe there are some distribution guys here in the room how to get people interested in backfixing that's a big question and how to get some contribution in non-technical areas that is also a big point for magia thanks