 Okay. Just cleaning the door first. So, hi. I'm Vincent Ounce. So first, I'm French, so it's not Vincent, it's Vincent, which is quite important, you know. So I'm going to talk about what we are doing in the GNOME team, what's new, since the last year, what has changed in the workflow, basically. Lots have changed, and I guess it's quite interesting for that. But first, let me talk just a bit about myself, because I mean, I'm beautiful. I think it's quite clear. And it's important to show that I'm one of the most beautiful person on the planet, so, yeah. Also, I'm really serious, as you can see. But my point is that I'm also, oops, like that. So, stupid, love thing, idiot. You can just come to me, talk to me, make some comments. I will always be happy and have time for you. So don't hesitate to come to me or drop me a mail or whatever. So, first, the motivation of the GNOME team. As you probably know, we have quite some, well, we have a small team in Novel, inside Novel, who is working on OpenSuzi, integrating GNOME in OpenSuzi. But we want to grow that team and to have people of the community to work on that team to do all the stuff we're doing, and the question is why? So, the first reply is this, that I don't like to work. So, I would like other people to do what I'm doing. That's the first reply. But it doesn't really work well, because actually I'm working a bit more since we're involving outside people than before. So, that's not really the good answer. The really, really, reality actual answer is that we want to do more stuff. We want to move faster and we want something which is better in the end. What does it mean? It means that we want to have more package. We want to update all the GNOME package faster. If you look at all the other distributions, when there's a new GNOME release, they have all the new versions of GNOME in two days. And we didn't choose to do that. Now we're doing that, actually. We start doing that. We want to do that better. What does it mean? Well, we want to have the better packaging. We want to have less bugs. All the usual stuff, actually. And it turns out that if you use, well, if you have a community who is doing that, the people who do that care about GNOME, and they will do something of good quality, because they really care. That's really a big difference. When you take people like me, I mean, I care about GNOME. Sure, but I'm paid, so I don't care that much, maybe. And that's not true, but I'm trying to explain the point. And so maybe I'm not doing the package that well. If you take the community, they will always do the right thing. That's the point, because they care. So it's a good thing for the long term. How are we... Figures first, maybe. I think that will probably explain the point of the GNOME community. First, the GNOME team maintains 10% of the package in OpenSUSE. So I'm just talking about the package that we have in OpenSUSE factory right now. Really, when you look at the numbers, it's really 10%. So that's a lot, really a lot. But you might say that it's all small packages that, I know, just the small utility. But actually, no, it's really 10%. If you look at the debug size of all packages, it's 10%, really. So it's big. It's really big, big, big. So it's a lot of work, and we need people to do that. Yeah, we're good. The GNOME team is really good. When we released OpenSUSE 11.1, we were frozen, and we were still frozen for a few weeks after that. And we had a small team of volunteers who started working on packaging the GNOME. And they did that in their own project in the build service. And so we merged that after a few weeks, and this result in 201 packages updated. And they were all done by the community, not by the people. So that's really impressive. And if you look at what we did last week, we did one packaging date to update to the latest GNOME, because we had a GNOME release last week. We made 100 submissions, basically. That's huge, really. In that, you have probably something like 16 new versions of packages and then fixes to the package. So we pushed all that to GNOME Factory, and we tried to make sure that everything compiled, everything is working fine. So that's really a ton of work. The daily life of the GNOME team. I will try to move fast into that, because you all know that, I guess. So we have a mailing list which is called OpenSUSE GNOME. We have an IC channel, OpenSUSE GNOME. We have lots of people on both. If you look at the mailing list, it's usually not that many mails, because people talk a lot on IC, actually, so it's good to join both. And if you look at the IC channel, it's quite friendly. People don't talk that much about OpenSUSE GNOME, but they just chat with each other. It makes really a good atmosphere, and it's working quite well, I think. So nothing is there to come. That's nice. We don't really kick people out of the channel, for example. We don't like that, that's bad. We have an ID page where people can put their idea they want to see become true in the future of OpenSUSE GNOME. And now we've decided with OpenFate to put all the ideas that are good enough and well-developed in OpenFate so that we can really track them and make sure that we don't lose track of everything. So we're quite happy with OpenFate. We're really happy that it's out and that people can use it. So it's good, good, good. It's really a good way to open to community even more. We have weekly meetings, so all the usual stuff. Yeah, thanks. We love OpenFate, really. Yeah, weekly meetings. We talk about what's new, the potential issue we have, what we want to do in the next week, for example. Do we want to do some specific event or stuff like that? Do we have some specific bugs we want to discuss, some specific features we want to discuss? People need to test something, things like that. And the important thing that we change the time of the meeting. So every two weeks we have a time shift meeting which is, I think, something like five hours later. So people who are in Australia or India or Asia, they can all join because the usual meeting is fine for European and American people, but not for Asian people or Australian, for example. So we want to include everybody, so that's why. And so we have specific events, like packaging days, like I already talked about. We have bug days where we have all the team going through Godzilla, all the bugs, and okay, we look at these bugs. Is this still valid in the latest release? Do we want to upstream it? All that stuff that we should already do and we didn't do in the past, actually. So now we're starting to do it really with the community. Upstream. That's probably one thing which I care really about because I come from upstream, actually. So I want OpenCity to be really good with upstream and have one of the best relationships with upstream. So what does it mean? It means accepting upstream. Accepting upstream is something which distribution used to not do that well, actually, the best. This means when upstream does a new feature and we do not like it, we sometimes use to remove that feature or to change the UI, to change the setting, but it doesn't help us in the end and it's something we have to maintain and that we cannot maintain. So we have to accept what upstream is doing and to go really with what upstream is doing. If we don't agree, we have to do that work upstream to change what upstream is doing, not to do that in the distribution. Also one important thing that we have is all the branding packages. I think it's a cool feature in OpenCity that a lot of people don't know about. All the settings and UI change that we do are done in a separate branding packages. So, for example, we have Gconf2 branding upstream and Gconf2 branding OpenCity and if you want to have the default look of GNOME from upstream, you just change this package from branding OpenCity to branding upstream and you're done. That's really quite awesome and when you talk to people from upstream, I did that a lot for them and they told me, yeah, OpenCity is cool, but I don't like the panel at the bottom. I really want to stock upstream and they didn't know about that. So it's really no other distribution is doing that, so that's pretty cool. It's a good way to accept upstream. We want to walk upstream, so that's what I did when we don't agree on features, walk upstream to fix that. This also means when we do a patch to fix a bug, the first thing to do is not to put the patch in the package. It's to send it upstream and then put it in the package. That's quite important. That also means that when we have all the old patches from, well, since 2000, I don't know what, maybe even 1999 or something like that, well, those patches were not set upstream and this is bad. So we have to send all those patches upstream. We had like 700 patches in GNOME and we did not know what the status was, whether it's sent upstream or not. We didn't know. So we start tagging patches with some keywords, like this is a patch for upstream or which is specific for OpenSusy because we need to integrate with this feature of YAST, for example. This is a patch which is a feature or just a bug fix and then we put the bug number from NovelBugZilla or bug number from GNOMEBugZilla and with small descriptions. This is really, really useful to get upstream all that we have and then to have less work on OpenSusy. Helping upstream is also quite important. A good example of that is probably what last week or two weeks ago I did a small script which exports all the tree of OpenSusy factories so we can have all the packages and people can see the files which are in the package, like all the patches of the spec file and they have a link to download that. So people didn't have that before. You couldn't just browse OpenSusy the source code. And for upstream it's quite useful to know what the distribution is doing with your module. I used to do that a lot and I'm still doing that from my upstream point of view. When I look at GNOMEPanel and I want to look at all the patches, I go on the Nubuntu website, I go on the Fedora CVS, I go on Mandrava SVN, stuff like that. And I couldn't do that before without opening a build service account for OpenSusy. And a lot of upstream people don't want to do that. They just want a simple web page. So we were not helping upstream. So I did a small script that exports all that and since then we had quite some many people looking at that. We had some people sending a small mail or an IC just chatting and telling, well there's this small thing in your package which is not quite right. So this is quite useful. So we want to also make it possible for upstream developers to use OpenSusy and feel comfortable with that. So it means when they want to develop GNOME, for example, we want to make it easy for them to just install one package on one meta package or whatever and then say, okay, now I can compile whatever I want from GNOME SVN. I have all the dependencies already installed. That's fine. So some black magic for them because they don't want to care if they want to only develop one small model upstream. We have to do that to help upstream develop stuff and we're planning to do all that. So the build service. The build service is probably something which changed completely the GNOME team because before the build service only novel people could walk on packages and now this has changed. So we were one of their first teams to really adopt completely the build service. When OpenSusy started being completely compiled in the build service, we completely switched all the people from the GNOME team. And there were some various reasons for that. Some people believed that it was better to use the same tools as outside contributors which I think is true. It's a good thing. And there were also people which were just annoyed that they had to use some VPN to access to the internal servers and they didn't want to use a VPN or whatever. But in the end, people just wanted to have this really same level of access than all other contributors. So we started doing that. We had some issues at the beginning. We lost some change that were done in the build service which were just disappearing in some white ways. But we're still happy in the end. We're also heavy users of it. And some people might have users because we have tons of packages. We have more than one project. So it's a really big usage of the build service resources that's really heavy. We're trying to work on that. We need to fix a few things. We might need to split the project. I don't exactly know. But we will fix our resources for that. So GNOME Factory. I'm not sure that everybody knows how we're working actually. So I'll try to explain quickly. Factory is the development distribution of OpenSuzi. And it's developed in the OpenSuzi factory in the build service. GNOME Factory is the project where all the GNOME updates are done and then when we're happy with them we pushed them to OpenSuzi Factory. So that's where all the action is going for the GNOME team. That's where we have all the 360 packages. It's moving quite fast. Lots of updates. It's cool. And we are trying to make that useful for daily use. So people can just use this repository and have the latest GNOME all the time. We're working on that. And some people already start using it on their main desktop. So that's pretty cool. But we have GNOME Factory. But then we have GNOME Factory Next, GNOME Stable, and more. So GNOME Factory Next is the next version of GNOME, the latest updates, when we cannot update in GNOME Factory because we're frozen, for example. So at the end of a development cycle, when we're just in bug-fix mode and some people want to start packaging the new stuff because they get excited about the new option features, they can go wild and do that in GNOME Factory Next. It's what they did back in December. So it's pretty cool. And so GNOME Factory Next is actually... People can just submit everything they want and the important review is done when we merge to GNOME Factory. And then we have GNOME Stable. So GNOME Stable is something we used to have and we stopped doing at some point and we are starting to do that again. It's just some projects to get the latest stable version of GNOME available. For example, in open-source event.one, we ship GNOME 224.1 or .2, a mix of both, actually. And upstream has continued to develop to some bug fixes and has released 224.3. So some users want to have that because they want to get the latest stable version of GNOME. They want just the fixes, not the new features. So we are starting to package all that. And we plan to do that for more than one distribution, actually. So right now, we are building GNOME Factory for Factory but also for open-source event.one, which means that GNOME 226 will be installable from open-source event.one if people don't want to upgrade. This is pretty cool. People like to not have to upgrade all the time their distribution but they might want to have the latest GNOME. So we're doing that. It's some overhead for us, but it's manageable. And users are happy, so that's pretty cool. With GNOME, this is really the cool stuff of this talk, actually. Really exciting. This is what made the build service really usable for us and this is how we are able to update all that stuff that quickly. So basically, OSC is the command line which is used to manage your package in the build service. And OSGNOME is a small plugin which is not that small anymore because it's like one-third of the code of OSC. So it's quite big, actually. But the goal is to make it easy to manage updates, to send an update and to build the stuff and to manage from the administrative point of view of the project's GNOME factory. So we have a few... We have a few subcommands. I'm missing a slide here. There's a slide which explains that we have some metadata on all packages. This metadata is about where is upstream located? Why can I get the latest table? And with all that, we have a script which goes up on the website upstream and downloads the latest table version so we can know what is the latest upstream version. We don't have anything that does that yet in OpenCD in a general way except macOScript which gets the latest version from SS feeds and stuff like that. This is a bit more stronger because you can put more stuff in. It's really reliable. So then we have OSC GNOME to-do. It uses this database which is on our website and you just run that and then you can see what you can do, actually. You just have some free time and you want to update to a new package so you type OSC GNOME to-do and, okay, I see that this package I can update to a new version and sometimes it's hard, sometimes it's easy. When it's easy and when it's hard, the first step is to do OSC GNOME update. This is really the magic command. This command does a branch of the package in your branch of DOM factory. It then downloads the branch checking out. It then downloads the latest option version table. It then adds this table to the build service, removes the old table, start updating the spec file to update the version, for example, start updating the change file to just put the header so that you update to the latest version. It extracts the news file or the changelog file. It shows you a diff of what's new. In the best case, what you have to do is open the change file, open the diff of the news file, copy-paste what's new, and commit. And you're done. So what you used to do manually before, it's black magic. It just run one command and it does all that. It's really, really cool. So this does the first part. Then you have build submit. Build submit is also quite awesome. This is a command which takes what you have in your local checkout, commits it, start a build on the build service, which means we have a policy in the branch for the DOM factory to not build by default because I have like 100 packages which are branched and I don't want them to be rebuilt all the time. I just want them to be built when I need that. So build submit starts the build, so it enables the build and build service and it waits so I can monitor what's going on. And after a while, when I see that it has succeeded on this architecture and on this one, it will just submit the new package to GNOME Factory. So the usual workflow you have is use OSignum to do, okay? You take, okay, Pango as a new release. OSignum update Pango. You don't know this stuff. Nothing to do, just magic. You change your local directory, CDPango. You open the .change file. You open the diff of the news. Copy paste. OSignum build submit and you're done. You let that stuff work. You do not have to monitor that if you don't want. So you can update that during the night and in the morning you will see that it has been submitted or not to GNOME Factory. So it's pretty cool. It's a good way to update like five or 10 packages at the same time without carrying that much if it's easy to do. This explains why we have some people who are able to do all that work easily. So with that, we enable all the community to do the artwork for us, which is pretty cool because, I mean, this was my goal on the first slide. Do you remember? I did not want to do anything anymore. But then, actually, that's not true because we have to review all the change. We have to make sure that people are doing the right thing. And so now, what I used to do, packaging has changed to reviewing change, which is actually not easier. It takes even more time. But the good thing is that after a while, we'll get the people who are building all these packages. They will just do the right thing, the package the right way. They won't do it errors anymore. And my review will be just, oh, perfect, accept. And so I will have nothing to do anymore. So yeah, good. I will be happy. So this is really how we start building the GNOME development team in OpenCG. As you probably saw earlier, we have people already doing all the weekly meetings, working on the week, working on the birthdays. They didn't need the build service for that. But having the build service in OS Ignome made more people come and it made the GNOME team more alive. So it was really critical to success. So we have a few people in the GNOME team, actually more than a few. If you look at IRC, we have probably like 60 people in average, I think, on the channel. And okay, not everybody is talking. And when you look at the stats, you have like three people who are really talking all the time. And they are not Nobel people, actually. So it's quite interesting. So we have some cool people. And the GNOME team, you have all these lists of people. I won't read their name because I wouldn't be able to pronounce this one, for example, correctly, I guess. So just to show that. And if you look at that list, I think you have something like five people working at Novel on OpenSuzi. You have one person working at Novel on Linux, things but while thread. And all the other people are volunteers. And they are doing all the work, actually. Everybody there is doing all the work. And so this is just a small selection. Way, way, way, many more people, actually. And I just did that list a few minutes ago, so it's not complete at all. But it shows you that we don't have just Novel people, and that this is just the beginning. We want more people than that in GNOME team. So yeah, but we're doing good. So that's quite cool. And also we have two people, Federico and Brian, which both of them are on the OpenSuzi board. So we're quite proud of that. That's something I didn't talk about before, but we are doing some stuff inside the GNOME team. But most of the people are quite active in OpenSuzi in general and not just in the GNOME team. So we have people who are on the board, for example. We have Magnus, who is quite involved in just testing the distribution factory, mailing, helping users, stuff like that, but not just for GNOME. All those people doing the same, actually. The stuff we are doing like OSG GNOME, well, it's good for GNOME, but truly it's something that we want the whole OpenSuzi community to use. So we have to work on that to make that available to everybody, to find a good way to integrate that in OSC directly, to integrate what we need to integrate in build services, if we can. We want also a small script that I did to browse the OpenSuzi source. It's useful for the GNOME team, it's useful for GNOME upstream, but it's also quite useful for all the people in OpenSuzi. So it's something that we want to be used, stuff like that. So we're trying to do our stuff first as a prototype for the GNOME team, but then we want to extend all that to OpenSuzi. What is working fine for us, I think, will work fine for all the people. So, yeah, I guess that's it. If you have any questions, I kept some time for questions, so I welcome all questions. Oh, microphone. Copying the package, is it copying the package, or is it creating a submit request? No, it's a build-submit. So build-submit is... it's commit from... I'll let you that, actually. Build-submit. It commits your stuff to your branch, it starts a build, and then it does a submit request. So it detects that your package is really a branch, it looks for the developer project, and commits it there. Well, not the developer project, the parent. OpenSuzi build. I want to add a package, I have a program, got a program somewhere else. I have to learn all of the stuff, make RBMs, and then... Oh, is it a question that... do you have to learn how to package? Yes. I want to add a package to... Okay, I'll leave you that, actually. Yeah, I want to add a package to OpenSuzi Pack 3 or OpenSuzi A11. I have to learn how to build RBMs. So if nobody has a package, what you want to package, yes. But the thing is that on the build service, you already have many, many people who have packages in terms of turf. So you're likely to find somebody who has done the work for you. Yeah. So usually, I mean, usually you won't have to build the package yourself, usually. Yeah, I will. Is the OSSignum command working for any other package that the package that are available in GNOME Factory? Because for example, if there is already a package that is existing on another project from the build service, can I use this package and branch it and submit it to the GNOME Factory? So the OSSignum code is quite generic now. We actually have other projects which are usable with it. I just have to know which project we want to use for that so I can create the database on the website for that. And then when you use OSSignum, use your OSSignum dash, dash project and the name of the project. So, yeah, you can use it with whatever you want. We just need to know on the server side that you want to use it so that we can create the database for you. Okay, and if I don't want to use a submit command, can I use it without any database? So you can use OSSignum build which is like build submit but it does not do the last step which is submitting to the parent project. So you can start the build, monitor what's going on and it will tell you if it has failed or succeeded. Which is pretty cool too. Any other question? Okay, thanks.