 First I will just do a very brief overview of the build service, I will not bore you about all the details as it is before the build specialised on what we are doing as a woman and where we want to go. Who has used the build service in this room already? Who wanted to use it? Did you fail or? You want the future to use it, ok. So for now I will just make a brief overview, afterwards I will just talk a bit about the backend interface where we are going to and the professor is probably, and later on we will make a workshop also of the best practices for packaging and so on. And inside of that you can of course find us always as a booth and we can help you with building your stuff. So the just a brief overview of what we did, started to work on the build service at all is we wanted to open up to the distribution development in the public. With the open business project, the complete distribution development should be public, everybody should be able to take part. The system is still used for generating our distributions is a system which was never intended to be to run on a public service. It's a pure in-house development and it works also only if you have NFS and such stuff. So we needed, we see the need that we needed a new system and we of course saw all the problems we have with our old one and we want to do it better. Inside of that is such a public service, completing new opportunities as they are what we can offer more for people and attract more people to come to us. We wanted really to make it easy to make packages, not that it's just only a pex card job. Of course also a pex card should be able to use it, but it should become also easy for an individual developer who has no clue about packaging. He's maybe a very clever developer knowing C++ perfectly, but even these people have or don't want to learn everything about spec files and so on because it's not interesting for them. Another thing is we want to increase the transference how we at all develop a distribution. This is very important because it's a very complex process and especially when you want to make or to allow other people to make delivery of a distribution it must be very transparent that everybody knows how we can influence the distribution building. And just a single current script which do some magic hex is not what we understand in transference. Another thing what we get is to attract more developers, developers want to spread out their software to their users. So it's a little solution where everybody can really easily create software, release it any minute he wants to and as long as we have enough resources in our system he gets immediately the packages and all his users can get these packages. So it's really a one button thing in the end and the users get all this latest software so you can reduce the turnaround cycles a lot and get way better and way faster feedback. And of course we want to get the contacts also to source communities. We want that they come to us, we want to offer them something that they don't have yet and we hope also that they give us something from them because they work with our system. We get all the latest, greatest software. And the last point is a completely different view. This is a view of the end user. The end user doesn't care about what packaging works. He wants to have latest software. He wants to get new software. He wants to learn about new cool stuff he never has seen yet and he wants to install it easily. So in the end the build service has two phases. One is the developer side. Developers put in sources, they add some modifications to existing sources. For instance they add a multimedia patch to the kernel. The QA forks tries to automate the tests so that they don't have manual works. They get the quality checks at any time, redone if some developer is changing something. And the distribution definition is also a topic to be discussed depending on the case. Hey, add this package and remove this package or update and so on. And also the process should be also become transparent and is then part of the project file. On the other hand the end user needs to have a place where it's optimized for him to use all the software he should be able to find. And what's advantage of this is when he connects his system etc. it's a feedback channel. So what already is there is if someone builds a package there, builds a project, he sees how many people are installing it. Because it's a download rate director, he counts how many people clicked on it, the guest or you or whatever installer used the URLs and he reports this back to the developer. So at the end when they are from the same package, different flamers, for instance the SDKs3b, playing then the SDKs3b with additional great application patches, you can see what the people are really using and what they prefer from these flamers. What helps us to optimize our distribution to use the best one. So the build source itself. The build source itself is a set of servers. So it connects to the internet, it provides interfaces and behind these there are build systems which build always the software which gets uploaded. Or because you have changed some package below, other packages may get need to rebuild. Because when we upload for instance a new compiler, everything needs to be at equal because a new compiler most likely has some effect on all packages. As tools, faith to the author is the API, on top of that there are multiple interfaces, one is the web interface, other one is a very important tool is the command line interface. The command line interface runs on your system, your workstation and allows you to do things which are not really easy doable on the server side. For instance you can set up the build process as it's done on the server also on your workstation, it's a one minor. This is important for instance when the build fails and the log file doesn't explain you really what happens, what went wrong. So see you can redo the build on your workstation and jump in and really find out what's really getting wrong. And in the end upload the sources again. So see it's a very SVN like command tool, very easy to use, at least for developers. So the build service was not completely open in the beginning, but we worked out and it will complete open source solution now. So it is as open as you can get it in any phase. The complete source code is free and open, it's available on the GPLV tool license at the moment. Our instance has an API open for everybody. So you can control all our build jobs on the server via rest commands. HTTP commands, you can script it via call, you can integrate it in any existing tools. Of course we can also use a command line client to communicate with the server. A very important and strategic decision was not to limit it to user-based distributions. And actually it's also not limited to RPM-based distributions. So we built already for deviant in depth format, if you uploaded in the description. And we uploaded for various RPM-based distributions. Since lately we support even surveyed enterprise server, besides user enterprise server of course. So independent if you are building for deviant, for Ubuntu, for main driver, for various open-susel, for the suselinox enterprise or for head enterprise, you can upload your source once. And if it works, as your source works, it builds for all distribution at once. The integration with existing web pages, that means that you have some homepage somewhere about your software project and you want to show what's currently active in the build service. This could be nicer, this is just, there are possibly other links, but you can have direct links to your software and build service where your users can install it. If your user is using open-susel-based distribution, they can do it with a run-on. It's really easy, thanks to Benji. The project model is a great power to build service in deviant. This is a concept I just want to show completely mentioned here. It was founded because of the reason for one thing, we want to stabilize our core distribution. We want to have it a high quality. We want to have it reviewed sources only, but it's not broken all the time. There are no evil things happening inside, so that really every developer can trust this distribution. On the other hand, we want to enable everybody to submit sources immediately. Everybody should be allowed and is allowed right now to upload sources, to build their stuff immediately and to get their results immediately, to feed their packages to their users. For that reason, in the build service we have work spaces. Everybody gets their own work space and people can organize themselves again in work spaces. If you are a group of five people, you can find one work space, you can define who should be able to change something inside, you can upload the sources and stuff, and you can define for what do you want to build. You can already use it as a collaboration tool to build or to work together on your projects. Just an example visualization is a very simple example. So there is a KDE4 project. Actually, we have multiple KDE4 projects. In this KDE4 project, there are a number of sources, and the project defines for what it gets built. So if someone changes something in KDE base, for instance, it gets rebuilt for open-source attempt tool, open-source effectively, KDEvian project. In this example, a number of people started to work also on a project, and they wanted to build, a number of heads needs KDE4 problem list. If they build it directly against open-source attempt tool, it will not build because there is no KDE4 for open-source. Now the nice thing of this project model is now you can stack it. So they can reuse the existing work of the KDE4 people and build against them. Everything that's not inside here gets taken from open-source attempt tool, but there's no reason to duplicate the work. If there are groups which do part of that what you need, you can reuse it. The project model in the end is way more complex. You can do really interesting and cool stuff, but it would be a longer talk. So the current situation is everybody can go to build open-source.org. It's the same account that we use for the Viki or for the Parxilla. You get an account immediately if you don't have one yet. You can upload your sources, you can trade your project, and depending on what you are uploading, you get packages immediately. The packages get distributed to mirrors who want to do it. The packages are available really fast for users. The end user can search it. What's there in our build service? This interface is relatively simple. We want to work later on this one. Maybe the integrated with a planned community portal, which is done by Pascal and Liza and Benji and Francis. What we are working on at the moment is to make it to improve the collaboration system. So that means that really more people are really working better together and especially to contribute also directly to our upstream distribution. Factory is our upstream distribution. For several reasons. We do not want to allow everybody to find directly to our upstream distribution because, for instance, we need a trusted-based distribution. So if everybody can change something there and steal your credit cards forever, it's not that this distribution would be trusted anymore. Therefore, you make a system where you can prepare your branch, you can prepare your package and request afterwards to merge it back so it gets reviewed. This works not only with the factory distribution, this works between all projects. So if you start a project and some random guy found a box there, you may get a merged request because he fixed something. And as usual, if he makes good contribution, you can add him so he can directly work on your project. Another interesting thing is the interface services and communication. This would allow us that when you have a known idea what you want to build and it's a large project. For instance, we want to rebuild our complete distributions but for MIPS secret use. And we don't offer MIPS in our infrastructure. Then you can set up your own build service. We have already packages there so it's easy to install. And you can rebuild the distribution in your definition, in your environment, in your public or in your in-house development. Another important thing is we should become more self-friendly Andreas and Robert will talk about that afterwards. We are working on integrating the image building. It's important that you can make the complete distribution building part of it so that the ISO images should be generated as well. Class is working on the notifications so that you don't need to poll anymore what's changing that you can subscribe. That will give me all changes. For instance, all source changes open to the factory. You will get notified. And of course the general improvements. These are just a list of what I see possible what we work on later this year. But I'm not sure. Of course, the complete distribution building support this means especially the maintenance handling so that we can provide security updates also. Another important thing is the trust system. This is what we really lack at the moment. An end user has at the moment really a good chance to decide if he can trust the software which is there or not. He can see in which project it's built, he can see the people who have right access there and he can decide if he trusts these people or not. But in most cases he does not know these people. So therefore a system which rates these people would help us a lot. And then the end user can say he needs for this system a level of something. Otherwise he would not like to install it. So such a trust system would help us a lot. Another important thing which became more important lately is the LSP conformance. LSP defines a set of libraries and APIs. And if you only use them, theoretically your application or package should run on every Linux distribution. The problem is how to guarantee this. There are tools out there which try to validate this and so on. But it's really hard to build the LSP conform package. And we think we can help there a lot by offering a target which really tells you what you shouldn't use and that you can fix it until it's really LSP conform. So if you succeed in this environment to build a package you can be relatively sure that it works and all the LSP's are most LSP distributions today. And you want to integrate also the QA and a QA interface that automated test cases are after each build can get run and we see differences. So if a new compiler breaks something we would see it directly. So of course there are lots of ideas collected in the Dickey. In general if you want to look at it go to build.opens.org that's a web interface and there are links to documentation to the IRC channel. It's an amazing list if you have a question. Or at Fostum of course come to our booth and we'll show you something if you have a question. I'll help you build this package. Thank you very much. I'm going to turn it over to Andreas. We are talking about the open to build service specifically about the design of the web client and how we want to improve it to make it more usable for especially beginning users that don't want to use the command line interface for any reason or I'm having to stop it probably. He's the designer for the build service and also for the other open to build software pages like the software open to build and users open to build and we keep together with from Sondheim we designed the general look and feel of those web pages and we will also talk about what they thought while designing those and why they designed this. Okay. The general outline is I will first talk about the current design and how it is lacking and then probably we will talk about the basics of the web design of the open to build pages and after that I will talk about what is changed and what is planned to change and then we will have a short demonstration about what we are working right at the moment this is heavily working focus so it doesn't... Yeah, you will see later. Okay. First about the problems. Generally when we started to develop the build service we didn't have a really good plan how to design a web page for this and so we started developing the underlying system and on top of that while developing the systems develop the web pages therefore the web pages are heavily based on the underlying data model like the project model every and talk about and therefore it's not very... it's not very intuitive to use you have to have a basic understanding of how the underlying model works to use the pages for example we split the project page and the package pages they look like completely different or they look like different pages where they could be combined in one page or the relation between a package and the project could be more obvious in those pages Another thing is, yeah it's grown with development as I said and the navigation it's not really consistent like for example to add a new project you can create a sub-project and if you... this would add a project below the... below this project like home call enforcement, call on something else like test and to create a project outside of this namespace you would have to navigate to the project list click on home projects including home projects and then navigate to the bottom and then you have creating a project which is, yeah, it's a bit strange I'd say and also we have navigation up here with navigation at the sidebar and it's not really... you don't know at the first step where you find where you want to go this is what we want to investigate a little bit how one would move on this webpage and improve okay next thing is I will hand over to Robert and he will talk about the general of Susie Webster here we see there are three main pages from open zoos it's the wiki or rather the green theme used as well in the shop and news open zoos a lot the orange one is from software and the grey one as you saw on the windows and but as you can see they always have the same concept we have the upper part which is for orientation local navigation which means you have web pages mixed up like wiki pages of the same wiki page in other languages and you have if there is one personal navigation and you have this in the wiki and in the build service for example and if there is a search or a search for the whole page it's placed here and for a content area there is news so you see you have the logo of open zoos you have these looks very good to see but you have the open zoos box where you have all open zoos pages these boxes on all open zoos pages so if you get lost in hyperspace this is your anchor what is the specific page? local navigation and here you see the wiki specific stuff, the search and the content area the third column is as well part of content the pages are color coded just to give more make it easier for people for example a few tabs open in mozilla so that they see this tab is my wiki because I have a green decoder in the tab I have an orange page on my software and so on and community so we try to keep this color model and make it easier for people to navigate and to know where they are that was my first part the things we want to change on the web line is first thing we want to make the web line more focused on the starting users or the users not used to the command line because the more advanced users have OC is a very powerful tool our command line interface this means that not every functionality will be there just basic like creating packages creating new projects search for packages change specific properties which are easy to change like description or the name of the project not the name title of the project and more advanced stuff will be available via OC and via direct editing of the metadata which is XML data another thing we want to work on is an easier way to see the status of packages what we have now is we have here on this area if this would be the reviewer service you would see numbers of packages that are failed or broken or that are in a specific state right now this is not possible because it's a bit of running on this machine and it has no real backend so there are no real results and we can see also we have the monitor page and what we thought about is mainly made the different repositories that one has available via tabs and all of these tabs to reflect the general state of packages belong to this repository this is just a thought and as with the other things we will try to implement it and then put it online and if it works we will change it another thing is we don't want to show actions that users can't execute on specific actions on specific projects they don't for example now I am in my own project which I can fully edit I can create subprojects I can delete project I can edit information and add packages I can just do anything if I now go to another project like for example Apache you see I am not mentioned here in the main which means I don't have any rights but I see the links to delete the project add packages and add information this is a bit confusing to users they think they can do stuff but in reality they can't so this is what we want to change this needs a bit of work on the backend side also because we have to export this data but this is overworking for us another thing is what we want to do is guessing the project actions a certain user wants to work on which means for example right now the ability to go directly to my own project and I have the ability to see a list of all projects in the builders and that's it what we want to do is also create lists for projects I am involved in like this test project I am also maintainer and right now I have only the possibility to find this project by either adding it to the my watchlist or navigating to the complete project list we want to show a list of projects where one user is added as a maintainer and then therefore make it possible to quickly go to the project I am interested also what we think about is creating a list of projects where a user has recently changed something or has recently viewed this is also probably a project you might be interested in so what we want is show this on the user's home page the user's home page is at the moment not used very much so we want to show those lists on this page ok, more things let's make certain actions on projects for example available when editing a package this is like I said previously when I choose to edit a package the project page completely disappears as reference point I only have this link up there you can see and this text here what would be possible for example is that part of the information will still be shown on the upper page on the upper part of this page and the package details on the lower page and also we want to more heavily use in place editing instead of linking to a dedicated edit page this reduces the different pages the user sees and for example when I want to add a user right now it opens a completely different page what could also happen is like in many web.o pages you see like thinking on add user and then popping up a form right below that using heavy PR strip or whatever and we want to we want to do this more in the future now I'll pass over to Robert few last words we're working the new repository page will be the mandatory repository page and what we did is that you now can see recent repository we often use and you can and you see I go there in my box type with your selection and you can just and you can just drag and drop it over and have it it's a test machine not so yeah it should appear there of course I knew that something like this would happen we made a part of the concept this might be just this is cumbra we would not call it alpha really far away from this point the movement yeah normally you just take it drag it to the drop zone and that means at the repository you have it in your drop zone and you can really able in the future to add more other repositories to these repositories we made and it's just the idea behind this is just to use natural movement or things just if you want something take it and drag it to your box like I don't know I walk through a shop and I want the apple I take the apple and drop it to my bag and can you show the picture okay I'm sorry it will be yeah but that is what we want to do but this is what we want to do but this is a taste of this with a build service that you just can do things and not have to think about what's the way how you can interact with these web group questions something or what said really good work can just contact them if there's any questions or suggestions after we come the colors come from the repository page the yeah I wake up in the morning and I copy it but orange is great I think this one from the distribution so I went to the Dora page I took a red or blue from the page they used mainly in the pages so it's easier for a web user to find this tool so that the project can define it with the project now those repositories you see in this list these are really fine by us those are the I call them base repositories they they complete this distribution they provide this distribution to build packages upon them you see different distributions what you could also do is I will show this on the old page this is the equivalent to this list this is as it is at the moment the build service has many repositories more because every project that creates a new repository can be used by another project to build against which means I think Adrian mentioned this quickly you can have a project that for example in my own project I added a repository using the Susie factory as a base repository this automatically creates another repository which other projects can use themselves and those won't get color coded they will appear down there if it will work and what you could do is filter maybe by KDE and only projects that have KDE in name will appear down there it will be much easier to medicate as the old list just a simple list box containing all those repositories no questions? then thanks for listening and have fun using the build service