 So, I see that everybody was here already for the overview talk, which is quite nice, because then I can skip the first part of my presentation, which will be about how to collaborate in the opens with the build service. And the general content will be, what do I mean with collaborate? How does the build service allow me to do that? And in the end, show you some examples how people are doing it right now. So first, what part? As Adrian nicely explained, the build service is just, if you never heard of it, it's something and I'm pretty sure for somebody that never heard of it, it's total chaos. You get projects and packages and builds and repositories and there are maintainers and command line clients, blah, blah, blah. So, I just want to make clear what the build service really is. The build service is a maintainer, creates a project which contains a package or more packages. The package contains sources and spec files which then get built and the result is a repository containing binary packages. So, that's the part where the end users are, that's the part where the developers are. So, with that cleared up, let's have a look at how the build service supports me in collaboration with others. So there are two hooks you have to collaborate in the build service, two easy hooks. The one is based on the project level which, as we can recall, is just some place that contains one or more packages. The other one is as a package level, that means I can do a contribution purely on a package level. So, if I have more than one package in my repository, I can collaborate with Adrian on one but not the other. So, first is how do I collaborate on a project level? It's fairly easy. You can either in the web client, you can either click add user and I can, for my project, add Adrian as another maintainer and be done with it. So, Adrian has all the same rights that I have. You can add packages, delete packages, submit other code or submit patches, everything. So I can do it in the web client with a simple click or I can do it in a command line client. Like I've shown here, which is just not a good font, so it wandered down, but it's just adding one line to some XML file. So I have my project, I'm the maintainer of that project and I added just another user as maintainer, in this case, Derek's. So this is collaboration on the project level. So now me, Hennel and Derek's can do everything in that project. Like I told you before, I can have another easy hook to collaborate, which is the package. And surprisingly enough, it is totally the same. We have just another XML file and I can just add another line and collaborate on the package. The same way on the web client, I can just add user as maintainer. So in this case, I have rights to do something to that package, like adding another patch, updating it, whatever, changing configure lines, whatever. And I just granted Derek's the same rights. So this is the second easy hook to do collaboration. And then there is the usual practice we have in the open source world that people are just saying, oh, no problem, just submit me a patch. And this is the usual case because nobody wants others to mess with his own system. So if I don't want people to add packages to my project, remove packages from my project, if I don't want to have people, other people than me to have the ability to change one single package, I can always say, OK, come on, submit me a patch. So there is tooling for that in the open source build service. I mean, it's always easy to just do that. I mean, come up to someone and say, dude, I've updated your package to 1.1. I made you a patch, and that's easy, but we have tooling around that process. So the same as this you can do with an OC command, which means obviously if I updated Pascal's package, then I had a look at the package, I grabbed it from somewhere, I gone over it, did my changes, now I have them compiled in the patch, and I say to Pascal, oh, come on, I submit it to you. So the same as just here as tooling in the open source build service means I just get Pascal's package from somewhere, which is OC branch. So I branch it from Pascal's project. This will create a copy of that package in a project of mine, which is under my home in the open source build service, which is I then can check out. So I have the actual files on my system can do my changes and can do the telling Pascal that I have updated his foo to 1.1 and telling him that I mailed him a patch. I can do that with a command too. I can just do OC submit request, create, and then create a patch from my project, which I updated to his version, which is not updated, and Pascal gets a mail and we'll see that there is a submit request for his package foo. So from Pascal's side, this looks like, OK, there is a submit request. If there's more than one, you can list them on his project and you can look at what I did with the tool, which is submit back show. So either Pascal knows, oh, I like that, then he commits it to his tree, or you can say, no, it's nice that you've done that and I can take 90% of it, but there is stuff that I won't take. So he can either accept these or not accept these. And if he not accept these, I get a mail again and he can tell me in that mail, OK, you updated to version 1.1, but you changed this one config, which I don't like, I want to have it otherwise, and stuff like that. So the whole process of two people talking to each other is like automated in the tool, which makes it easy to scale it up. So I mean, if me and Pascal talk, it's probably better if we do it on some IRC channel than to me branching his package and blah, blah, blah, blah. But if you have more than two users involved, it really gets easy to get mixed up in that. So tooling around this process is really nice. So what I want to show you is now some examples of how people do stuff and collaborate in the build service today. As you can imagine, this tooling I just showed you, you can use it in all kinds of ways. For instance, we have a new repository in the OpenSuser project, which is called Contrip, which is kind of a universal third-party package repository, where people that are not directly contributing to the OpenSuser factory have some place to put packages in. So with the tooling we have for OpenSuser factory Contrip, which is the development branch, we do it like this. For new packages, if you want to submit your package that didn't exist before in factory Contrip, you have to do a submit request, which means you have to do this, oh, I have this new package, I sent you a patch that adds it to your repository. Then there are people more than, I mean, there's a whole team behind that that just reviews the submit request that come in for new packages. Once you are granted access to that package, to the repository, you are the package maintainer. You are not the repository maintainer that means the only thing you can change is your own package. You cannot add another one, you cannot remove other packages, you cannot do anything to the repository, you can only do stuff to your own package. This means process-wise, if you update a package, you just work on it and check in and stuff like that. If you don't want to maintain it anymore in that repository, if you say, okay, maybe I maintain KDE 2 in it and now KDE 4 is there, so I want to get rid of it because everybody has moved on to KDE 4 anyway, I can just drop it, for instance. So I can do whatever I want to my package but not to the repository. Then there's kind of an extra repository for every released version of OpenSUSE. So for instance, with 11.2, we will have 11.2 Contrib where the tooling and the process is completely different. So new packages are simply not allowed. The project maintainers means that can do stuff to the project like deleting packages and stuff like that or having it built for some other distribution or whatever are still the Contrib team. In this case, for the individual packages, the maintainers are also the Contrib team which means if you had your package in factory Contrib, you could do everything. If it wandered to 11.2 Contrib, you can't do anything. For everything you do to that package, you have to submit a patch again. So you can see in that example that we are trying to follow the general factory rule we have at the moment. This is unreadable, so I can explain it a little bit. This is actually the usual OpenSUSE development model. On the upper line you have the factory stream which is just like in your SVN, your head branch or whatever, always the newest stuff. Then somewhere at some point in time we start the development of 11.2, then do something, release alphas, bethas and then gold masters and then somewhere in time the development for 11.2 stops and we branch away 11.2 and have the same here. So this is the general OpenSUSE development model which is kind of reflected here. You can do everything in factory, you can do shit in release projects. So this is how we today in OpenSUSE Contrib use the tooling around the OpenSUSE build service to just have a repository that follows the general OpenSUSE development model. So how do we do it today for factory which is the OpenSUSE development distribution? At the moment we have for each package in the distribution we have someone directly responsible as maintainer which means it's kind of easy to set tooling up around that because if you want to submit something to the VIM package of OpenSUSE factory you have to go to the VIM maintainer and tell him I have changed this and that and that and can send you a patch. So the idea at the moment is that you just do a submit request to the OpenSUSE factory VIM package and the VIM maintainer takes care of all the OpenSUSE factory VIM submit requests. This is how we are doing it now which kind of scales badly because for every package you need someone directly responsible which means if we have like today somewhat 3,000 packages you have like either you add more people that care for factory if you add more packages or the package count for individual developers goes up and what we see at the moment in the OpenSUSE build services that factory cannot really keep up anymore because you need to find other methods than having someone directly responsible for a package and this is kind of the state we are at now and where we are trying to come up with solutions and one of the things we thought of in the moment is to have some kind of review team like the OpenSUSE account team that is not directly responsible for one package but where people reviewing just simple patches and stuff like that and that's the way we currently think we can do it but there we are in discussions and that is because for factory there are a lot of restrictions for instance factory gets used to build a lot of other packages so if you submit something to factory it gets immediately used for building other stuff and a lot of stuff like the whole build service. I mean every project in the build service at least every OpenSUSE project has an OpenSUSE factory branch where they build against factory so that's one restriction we have that there has to be some review otherwise you can't do it and then there has to be some scheduling because I mean if all of you have one after the other great ideas for the G-Lib C package and you submit and submit and submit and submit nothing will ever get built because if G-Lib C changes like the whole system changes and gets rebuilt so if you check something into G-Lib C and then you and then you nothing gets ever built that's another thing we need to do with factory scheduling and as you can see there are a lot of restrictions but I think the tooling around the OpenSUSE build service is actually equipped to handle that so that's the current state of collaboration in the OpenSUSE build service if you need me to show you stuff we can go down to the booth and I can show you how to set up your project to handle the different roles of maintainers and stuff like that or I can show you how submit request really looks like and not on a slide but in real life and stuff like that and if you have other questions you can ask them too so are there any questions now you would like me to answer yeah yeah you talk about branching and I have two questions related to that when you branch a package if the original package it's changed do you get a notification of that no no not really you could get a notification but it actually it's not needed because the branching works with the sourcing mechanism that means that you are in your branch project has a reference to the original one still and when you change something the build service is storing your change so when the other guy is what you link to is changing also the system automatically tries to merge both changes and it's still working of course there can be the situation that stuff is conflicting and there we still have a problem that the merge handling is not nice enough this is something that we need to work on at the moment but in theory you can that's also a good thing when there are for example five submit requests to one package and now you accept the first one and then you see okay the other four three of them are still applying but one one is not anymore so you can decline please adapt it again and the other three we can see okay from then I take I take that one and then you can see if the other bows are still working so it's as long as as emerges are the changes are not conflicting it's really easy to see if they have an influence to each other and to merge them together just the manual merge conflict solving tool is not there where it should be that's something we what we need to improve my question was more on the like if I branch your package and I want I want to maintain that branch not that you want to merge my patch on yours like I have my patch and every time you do a new version I will get my my branch revealed so that's the same as the sourcing mechanism I mean that's the example with the corner you have the corner and you want the multimedia patch but the kernel developers don't want it because it reduces the speed of the Oracle database then you can perfectly easily set up your branch project this is sourcing and this is what happens in the end with the branch command at your patch and as long as your patch applies you will all the time get the latest package plus your patch compiled so if the other guy is changing something some source your package gets compiled also again so to to to make that quick this OC branch command does nothing else than creating another project underneath your home project and linking the sources can you close can you close a branch sorry can you close a branch like you open a branch and you maintain that branch but when it's merged to the original you just delete the project you delete the project okay and then you said you talk about the country the country team who is the country team is a suzia employees you mean no what I mean I mean there are Susan employees I for instance and I'm in the country team but there are others as well that are not employed by Susie or anything so but what's the difference I mean how someone gets in the country team you said you can we initially started just doing a call and who wants to because it means work I mean you you have to review patches from all over the place and you have to review full packages and in the end if we have a released contract like for 11.2 you will have to review security patches and stuff like that so it means work so initially we just ask who wants to do it and those guys who said yes I know the country team so there was no there was no formal decision-making process or anything we just asked and be done with it yes if you if you yourself want to be maintainer of the country you can just come to the mailing list and say okay I want to help out but in the end we will probably clean up this team every once in a while and throw out people that are not contributing anymore and why do you have to have people I mean when people in the factory country has to be not the same on that on the country team sorry I mean you have people that would be in the factory country and people on the country why it's not just the same people no we have you have two repositories and you have one contract team that is caring for in factory contract only for new package submits so if a package that wasn't there before gets submitted to contrip here this this team has to take care of reviewing their package you are you are the package maintainer of the factory content let's for example I do a package and I ask for this package to be in the factory country and I'm the package maintainer then when this gets to country you mean when this gets to yeah I mean I could still be the package maintainer why it has to be a different person I can explain to you're not the package maintainer anymore because otherwise you could change whatever you want in a released state of the repository that means for the end users that use your packages they have a moving target all the time so we want to have quality packages in open user contrip so we follow the same rules as we have with factory which means for instance no new packages on in released repositories no version updates or only sparse version updates for security problems or we say okay we're not changing the way the the whole thing is built too often so we don't get rebuilt too often and stuff like that so that's why package maintainers individual package maintainers cannot maintain their own stuff in a release state of the country repository anymore that's the stuff the contract team will care for which does not mean you're not responsible anymore or do you're not you're not able to help anymore it's just not you cannot check in every time you want to yeah but I mean if you want to have a package that works with factory and you don't want to maintain that package you just have your home projects but if you want a package to be in the country I think you should be the one to to maintain that package there are probably some cases where the original maintainer is also in the country and he's then of course also maintaining his own package in the is not that in the in the moment that you joined in the moment you join the contract team you're no longer allowed to maintain your own package that's not the problem but if you're maintaining it for the contract team you have a different set of standards to obey to no version updates no oh that's a funny feature I enable it now no you can do that in factory but don't do that in the in the stable contract in there it's basically the same like we work at at Susie when we package I'm sometimes I would like to do a version update for a released version but it's very hard you need very good arguments to be able to do that what you need to keep in mind is that we want to have really lots of people using cron-tip and we want to have as much trust into this repository as possible what's important here is it's a visible service always the thing stuff gets build it automatically and people who have added this repository get directly affected so it's way more risky than with just an SVN where people can review it or usually any standard user but a package which gets installed is it gets installed as route and so the so there is some risk that it damages the system and especially for an unstable system like an open to the 11.2 there must be some review in our opinion to have to keep the trust and as you maybe can hear from the from the comments from Stefan and Adrian it's kind of my evil hidden plan to form factory contract after factory so in the end we can just merge them back together and have contributions to to factory directly and but first we need to resolve this this review step somehow because I mean factory contract will have a lot of users but factory has really a lot of users and you don't want to change stuff in there that breaks people's system or that opens root holes or whatever so there has to be a review and that's my personal evil plan how I designed factory contract to to adhere to the same standards as factory because in the end we will just merge them back together but that's stuff for the future and this is what we have now so any more questions okay then I'm finished early