Okay. Just closing the door first. So, hi, I'm Vincent Wundsen. 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. A lot has changed and I guess it's quite interesting for that.

But first, let me talk just a bit about myself because first, 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. Also, I'm really serious, as you can see.

But my point is that I'm also like that. So, stupid, law 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 Novell, inside Novell, who is working on OpenSUSE, integrating GNOME in OpenSUSE. 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 walk. So I would like other people to do what I'm doing. That's the first reply.

But it doesn't really walk well, because actually I'm walking a bit more, since we're involving outside people than before. So that's not really the good answer. The real 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 packages. We want to update all the GNOME packages 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 did not choose to do that. Now we're doing that, actually. We stopped doing that. And 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 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... Yeah, some 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 OpenCC 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 this 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 new GNOME. And they did that in their own project in the build service. And so we merged that after a few weeks, and this resulted in 201 packages updated. And they were all done by the community, not novel people.

So that's really impressive. And if you look at what we did last week, last week we did one packaging day 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 60 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 on 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.

And it makes really a good atmosphere, and it's why it's working quite well, I think. So, not a day to come. That's nice. We don't really kick people out of the channel, for example. We don't like that. We have a wiki page where people can put their ideas

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 is 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 in, 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 Bugzilla, all the bugs and, okay, we'll look at this bug. 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 OpenCT to be really good with upstream and have one of the best relationship with upstream. So what does it mean? It means accepting upstream. Accepting upstream is something which distribution used

to not do that well, actually, in the past. This means once 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 is that we have all the branding packages. I think it's a cool feature in OpenCT that a lot of people don't know about. All the settings and UI changes that we do are done in a separate branding package. So, for example, we have jconf2-branding-upstream

and jconf2-branding-openct. And if you want to have the default look of GNOME from upstream, you just change this package from branding-openct 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 at FuzzM and they told me,

yeah, OpenCT is cool but I don't like the panel at the bottom. Really, I want to talk upstream. And they didn't know about that. So 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 batch to fix a bug the first thing to do is not to put the batch 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 didn't know what the status was. Were they sent upstream or not? We didn't know. So we stopped tagging patches with some keywords like, this is a patch for upstream which is specific for OpenSUSE because we need to integrate with this feature

for example. This is a patch which is a feature or just a bug fix. And then we put the bug number from bugzilla novel bugzilla bug number from GNOME bugzilla and small descriptions. This is really really useful to get upstream all that we have

and then to have less work on OpenSUSE. Helping upstream is also quite important. A good example of that is probably Last week or two weeks ago I did a small script which exports all the tree of

OpenSUSE factories so we can have all the packages and people can see the files which are in the package like all the patches, the spec file and they have a link to download that. So people didn't have that before. You couldn't just browse OpenSUSE source code. And for upstream it's quite useful to know what the

description 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 GNOME panel and I want to look at all the patches I go on the Ubuntu website I go on the Fedora CVS I go on the Manjureva SVN stuff like that. And I couldn't do that before without opening a build service account

for OpenSUSE. And a lot of upstream people don't want to do that. They just want a simple webpage. So we were not helping upstream. So I did a small script that exports all that and since then we had quite so many people looking at that We had some people

sending a small mail or just chatting and telling 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 OpenSUSE 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 OK, now I can compare 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 module 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 people could work on packages and now this has changed. So we were one of the first team to really adopt completely the build service. When OpenSUSE started being completely compiled in the build service

we completely switched all the people from the GNOME team. And there was some reason for that. Some people believe 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. 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 was on the build service which were

just disappeared in some weird ways. But we're still happy in the end. We're also heavy users of it. And some people might say app 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. We don't exactly know, but yeah. 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 OpenSUSE and it's developed in the OpenSUSE 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 push them to OpenSUSE factory. So that's where all the action is going for the GNOME team, basically. yeah, that's why we have all the 360

whatever packages. It's moving quite fast, lots of updates. It's cool. 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. So 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 upstream 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. 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 it 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 OpenCC 11.1 we shipped GNOME 2.24.1 or .2, a mix of both actually. And Upstream has continued to develop to some bug fixes and has

released 2.24.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 OpenCC 11.1 which means that GNOME 2.26 will be installable from OpenCC 11.1 if people don't want to upgrade. This is pretty cool.

People like to not have to upgrade all the time the distribution, but they might want to have the latest GNOME. We are doing that. It's some overhead for us but it's manageable. 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 it's basically OSC is the

command line which is used to manage your package in the build service. And OSC GNOME 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 administrator point of view of the project GNOME factory. So we have a few subcommands. I'm missing a slide here. This 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 OSC in a general way except markerscript which gets some news which gets the latest version from stuff like that. This is a bit more stronger

because you can put more stuff and 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 ok, 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 GNOME factory it then downloads the branch, checking out it then downloads the latest option version it then adds this table to OSC to the build series, remove the old table start updating the spec file

to update the version, for example start updating the change file to just put the header, say that you update to the latest change latest option version, sorry and it extracts the news file or the changelog file it shows you a diff of what's new and so 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 blackmagic, it just runs one command

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 gnome-factory to not build by default I have like 100 packages which are branch

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 on the build service, and it waits and 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 os-gnome to do okay, you take okay, pango has a new release os-gnome update pango

you don't want this effort nothing to do, just magic you change your local directory cd pango you open the .change file you open the diff of the news copy paste os-gnome 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 on to gnome-factory, so it's pretty cool it's a good way to update like 5 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 hard work for us which is pretty cool because this was my goal on the first slide 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 errors anymore and my review will be just

oh, perfect, accept and so I will have nothing to do anymore so yeah, cool I will be happy so this is really how we start building the gnome development team in OpenCL as you probably saw earlier we have people already doing all the weekly meetings

working on the wiki working on the bug days they didn't need the build service for that but having the build service in OSG gnome 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 gnome team actually more than a few if you look at IRC we have probably like 60 people average, I think on the channel ok, not everybody is talking and when you look at the stats

you have like 3 people who are really talking all the time and they are not novel people actually so it's quite interesting but so we have some cool people and the gnome team you have all this list 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 5 people working at Novell on Open Suzy you have one person

working at Novell on Linux things but Sled and all the other people are volunteers and they are doing all the work actually, everybody there is doing all the work so this is just a small selection, there are 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 but we are doing good, that's quite cool and also

we have 2 people Federico and Brian both of them are on the Open Suzy board, so we are 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 Open Suzy in general, 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 OSC gnome well it's good for gnome, but truly it's something that we want all Open Suzy 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 and build services if we can we want also a small script that I did to browse the Open Suzy 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 Open Suzy so it's something that we want to be used, stuff like that so we are trying to do our stuff first as a prototype for the gnome team but then we want to extend all that to Open Suzy 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 so build submit is

it's commit from I'll let you that actually build submit it's build, it commits your stuff to your branch it starts build and then it does a submit request so it detects that your package is really a branch

it looks for the develop project and commits there well, not the develop project, the parent

Open Suzy build and I want to add a package a program, Java programs and somewhere else I have to learn all of this stuff and make RPMs and put it in

is your question that do you have to learn how to package? I want to add a package I'll leave you on that actually I want to add a package to Open Suzy factory or Open Suzy 11

RPMs so if nobody has packaged what you want to package yes but the thing about the build service you already have many many people who have packaged a ton of stuff so you're likely to find somebody who has done the work for you

yeah so, usually usually you won't have to build the package yourself usually I will

is the osc-gnome command working for any other package

the packages 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 to the GNOME factory so the osc-gnome 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 and the website for that and then when you use osc-gnome you use

your osc-gnome dash dash project and the name of the project yeah, you can use it whatever you want, we just need to know on the server side that you want to use it with this project so that we can create the database for you ok, and if I don't want to use the submit command can I use it without any database?

so you can use osc-gnome build which is like build submit but it does not do the last step which is submitting to the current 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 questions? ok, thanks