So, again, since I was a bit lazy, I didn't want to do a real talk, so again, going to be some discussion with you. That's really, I mean, that's easy for me. So, yeah, if you don't know me, I'm Vincent Oons.

I'm working on Gnome upstream, pretending to do a lot of stuff, but letting other people do the real work. And I'm also downstream because I'm packaging Gnome Bob and Susie. So I believe I have some good ideas of what's going upstream and the issues we have downstream too.

And the goal of this talk is to make sure that upstream and downstream are communicating, and so that we know... So, yeah, actually, how many people here are upstream Gnome people? Please raise your hand.

Something like 10 people, I forgot. And how many people are working on Gnome but downstream, packaging it, testing it, and stuff like that. So we have some of the people who are the same ones, but we have also different people as well.

And so, yeah, the idea that I really wanted to discuss all the things that we are doing right, and things that we are not doing good upstream and downstream from Gnome. So, again, feel free to interrupt me and start discussing about something completely different from what is on the slides.

That's what I want to see happen. So first I just wanted to introduce some communication channels that we have between upstream and downstream. It's really some general information that you should already know fully. So we have a distributed list mailing list, which is supposed to be a point of contact for downstream people to know what's going on upstream.

So, for example, if there are some really important bugs that have a fix, and that you should backport the fix for your stable distribution, a mail should be sent there. If you have an issue in your distribution, and you think that it's a really big issue, you should probably talk to people there.

We also have bugs that, of course, we have hierarchy and conferences where people can talk to each other. So it's all a classic story. I guess you all know about that. I'm not sure that there's a lot of things to tell about that. So one of the things I'm really interested in is all the things that are related to Gnome release.

Since I'm part of the release team, I'm trying to figure out if we're doing a good job, if we're communicating that greatly to downstream people, if downstream people have some comments to tell us about the release we do.

So I just put some topics like, are the releases we do of good quality? Is the six month schedule that we have good for you? Are you well aware of how it's done? Which version of module needs to be used for a specific release?

Do you know this information? Do you need to know it? Stuff like that. So I put a lot of stuff. So this is mostly for downstream people to get the feeling of if we're doing things right from the upstream perspective. Do you have enough information about all that? So some comments about that maybe from people.

Let me run again. Six months release or base time release, six months, one year is really useful for the distribution

because they know what to do and if it can help them take decision what version to load. Now we're talking only about the main component or all other applications which are hosted.

And for application I know that the release schedule is not so perfect. For example, rhythm box. So yeah, you would like the general GNOME applications to have a GNOME schedule?

Yes. So for example... Not really with GNOME. Well, to have a GNOME schedule. So for example, Vanchi people announced a few months ago that they would just use the GNOME schedule. Is it the kind of stuff that you would like to see?

Yes, so basically it would be nice to have somehow like a policy for an app to be GNOME compatible to have also GNOME. That makes sense. Anybody else? This is maybe a stupid question, but do you put the recommended build order packages in the release notes?

I remember they were there and some release like 2.4, 2.8, something like that. And then at one point you did not publish them any longer. Are they back?

So that's a good question. We don't have official order to build models. But you could use gsbuild to get that actually. If you use gsbuild...

What is it? List? Yeah, gsbuild list and GNOME desktop model set or whatever, something like that. You can get the order that we use when the release team smoke tests the GNOME release order that we use to build the models.

So we don't think it makes sense to publish that. Because when we did that a few years ago, it was mostly for end users who were providing GNOME 9 cells. And we thought that distributors would not have that kind of issue. But if you think that makes sense...

I think it made sense because I'm doing the GNOME packages for a VST system. And what I was doing with this build order was to provide a meta package that just builds them along the official order.

Ok, so it's really easy to do. So we just have to do it and that's good feedback to have. Any other comments on that? So I have one comment as downstream.

One issue I had when I packaged a new version for Ben Suzy. When an upstream module had a new configure option, for example. You usually read the change in the news file and the configure option might not be documented. Or if there is a new dependency which is useful for some feature, it might not be documented.

And that's an issue we have because a lot of modules are not using a really well formatted news file. And so we don't know what to change when we update the package. So I think upstream could do a better job at that. So something to keep in mind for upstream people I guess.

But the change to die. I have a problem with new releases.

You talk about the configuration options. A lot of times we have some problems with automatic dependencies. And sometimes upstream doesn't take long to apply some patches.

We give them to not build somewhere depending on somewhere we don't want to be dependent. I mean, if I want a genome without TIF support, for example, I can disable it.

But maybe a genome is within it automatically. Yeah, I saw some patches like that. That's true that sometimes it takes time to apply them. So that's generally the feedback while taking some time to apply the patches from Big Sura.

I didn't think I would have to run like that, I'm sorry. Regarding Debian point of view, we find sometimes new features are web app centric.

And they don't work on Ubuntu or Debian. The GDM new releases depend on X running on the first virtual turning off, for example.

And they don't work like that. Or for example, package sheets. Or they don't have any means to communicate with the user when operating, for example. And Debian depends on that.

It has the COM content and so on. I guess it wasn't thought like that. So that's a problem when GNOME pushes a technology which isn't ready for some of the bigger distribution of life.

Yeah, yeah, true, true. It took some time. I believe Richard for that. So for what he was saying, for example, when features are centric to some distribution, he was saying red app.

I mean it could be the same for OpenSUSE or Debian or whatever. Yeah, I know. I'm not sure that we are aware of that kind of stuff.

I mean the release team is not aware of that, for example. So maybe don't hesitate to contact the root team in such case. I think it's important. Any other comment on that? No? So let's try to move to the next slide.

Bugs. Oh yeah, bugs. What? Oh yeah, there are no bugs. Well, in GNOME we have tons of bugs unfortunately. But there are good bugs. So I've put some stuff about the bugs. That's from my experience.

I'm pretty sure that you all have some experience with bugs too. A lot of users don't really know about GNOME upstream and are reporting bugs directly downstream in the bugs that are in the distribution or launchpad if it's Ubuntu or dead bugs for Debian or whatever.

And so we have to make sure that downstream people are forwarding the bugs upstream. But it was only the relevant bugs, which is not always the case. And so that's the church part. And also when we have this one difficulty that when upstream has a bug followed from downstream and we need more information,

we put the bug in meaningful state, but the reporter downstream doesn't know about that. And so the bug doesn't move. So that's the kind of issue we have.

I would like to know what is the experience of people upstream, downstream about that. How do you feel about that? Is it globally doing okay? Are we doing fine? Or is this a big issue for people? Well, I'm both upstream and downstream.

As downstream, I'm usually unable to fix a bug or make sure that I know that this is a known bug, etc. So I usually tell people, fill your bug upstream directly.

Because if I do it for you, we will have the need info tracking problem. Because if I am a proxy between upstream and the user, you can be sure it works for one bug, for two bugs, for 100 bugs, it can't work.

So that's really an issue. And another thing that would be great, but I don't know if now bugzilla support it, would be to be able to migrate bugs between bugzilla.

If a user fills a bug on mandriva or suzi or whatever downstream, be able to push the bug. If we know that it's not a distro specific bug, push the bug upstream. And on the other hand, if there is a lot of reports from one specific distro upstream, be able to push the bug downstream.

So that would be great. I will give you the microphone, just one thing. As upstream, I had several bugs from users of distributions.

It could be gentle, it could be able to filter or whatever, it's not important. And it's a crash, and I look at the stack trace and it doesn't make any sense. And that's because there is a patch downstream. And that's highly annoying that this bug got forwarded to me, but it's not my fault.

So that's something to keep in mind from downstream people when you forward a bug, make sure that it's not your fault first. I was exactly on the same page because I'm just a simple user. My first behavior when I'm facing a bug is just to ping my distro specific packager to forward him the bug.

And it's up to him to say if it's a bug which is distro specific or non specific. And I think the point that Fadek just pointed out, it could be very useful for him because I'm addressing him the bug to be able to switch it to upstream.

Because he is going to say this bug is not going to allow radar or anything specific. This is a key point because if I'm reporting directly upstream, I would be told, as you just pointed out, please just check this is not a distro specific packager. And I think it could be a nice way not to overload the upstream team.

Just report to your distribution team and ask these people to forward upstream when it's needed only.

Well, speaking as a simple no-user here, every time I report a bug in GNOME bugzilla, I'm very afraid of the result. I use Fedora, so I will report the bug, it will be fixed or not.

And one year later, the same version will begin. And I have during three months duplicate, duplicate, duplicate, duplicate, duplicate. I only receive tens and even hundreds sometimes when they make the mistake of reporting against evolution of duplicates in my inbox.

And that really doesn't motivate me to report bugs upstream.

Okay, so for that case, it would be nice that if bugzilla had an option for the reporter simply to opt out of bugmail for that specific bug. And as far as I know, it still doesn't exist, but there's more than likely a ticket in bugzilla.mozilla.org that you could look out for.

Well, that's annoying also when you're an upstream developer because I'm getting those kind of things too. Anybody else? I think I saw a hand raised. No? Okay.

So we have to be careful about the bugs and how they are forwarded upstream to make sure that upstream also handles them as well. Then I wanted to talk about patches. Don't hesitate if you have another topic, by the way.

So, patches. As downstream, now I understand that sometimes we have to have patches. I used to not understand that, but now I cannot understand. And the main, main issue that I had when I started working on OpenSUSE is that we had tons of patches for Foggnome.

And they were not documented, they were not sent upstream, and so it was just a nightmare. So we have to make sure that we always send the patches upstream. We have to make sure also that it's easy for upstream people to see our patches because it's a common request. And there's also an open issue like when you need a specific feature and that upstream doesn't want it,

you end up with a patch that you will keep up for forever. And so how do you handle that? So, do you have any experience on that as upstream, like you didn't see any patches from distribution forever or whatever?

Or from downstream, how difficult it is? Why are you there? I was going to say about Ubuntu. I had a big problem with Ubuntu two or three years ago where the patches wouldn't ever go upstream.

And I, to give them their credit, have been a lot better in the last six months, nine months for me specifically, pushing bugs up to no bugzilla and also patches back up to the maintainer. So I know I've bitched about Ubuntu before and patches, I think, to this, I've given their dues, but it is getting better.

Who is taking pictures of me doing that?

So in fact I didn't have any specific patching experience with GNOME.

I'm the maintainer, but I'm not containing GNOME downstream. But still there's a shameless plug which is quite interesting here. So in the beginning I'm going to adapt a specific format to type patches. So basically there's a set of comments at the beginning of each patches where you say, I just chose simple stuff like the patch author and the patch description, but also the status of forwarding of the patch.

So you can write stuff. It has been forwarded upstream that day. It has been accepted by them that they released, et cetera. Ubuntu is going to accept the very same metadata, let's say, for type patches. And I've been speaking with Fedora guys which are going to consider it.

So maybe it's an interesting practice to consider at least. And if you're interested in the DEP, they can announce the proposal number 3, type patching guidelines. Who will do that? And also there's that track author.

I think there was a mention to the distributions meeting about that. Maybe. I don't remember. So it probably makes sense indeed to add as many distributions as possible to the same format. So we can easily know what's going on and the definition of such a patch.

And also, there is a website for Debian which is patchtriker.dbm.org, I think, which is amazing. It's finally easy to find a patch from a Debian package and I love that.

I know that Ubuntu is something like that, which is patches.ubuntu.com. It's also relatively easy but less easy. Fedora has the CVS which is browserable. Manjiva has the SVN which is browserable. OpenSUSE is not doing a good job there right now but I have a hack which is working fine.

So we have on the GNOME wiki, we have a list of links to all the patch trackers from distributions. So adding the patch easily findable is really a good step for making this. Anybody else on patches?

Two ideas. One which would be great. Since GNOME is using Git to have all these for each module to have a branch for each distro. So that easily upstream could get downstream patch.

Or even between downstream to be able to see what other distro has done. And another thing which is now becoming very useful is Git butzilla.

Being able when you are doing your patch on your package. In 10 seconds to be able to fill a bug with the patch attached. You don't have to open your browser, fill a 10 description line, attach a file, etc.

We have to make sure that for patch to be pushed upstream. It must be very easy to be sent upstream from downstream. I just have a question for the distro specific packages.

How much of your patches are distro specific? Is there anything which is common between all of them? Or does every single patch is distro specific? So in my case I know that I have some patches which are distro specific.

Because we don't have the same infrastructure below. So for example we have some integration with Yast which doesn't make sense upstream. And nobody else will care about that. So it really depends. But in general, I don't know for the distribution but I expect that most patches are not distro specific.

So very few chance to have a common thread before upstream. Sometimes we have stuff which is... We were discussing that some hours ago. Sometimes there are patches which are distro useful.

Which could be cross distro useful but which are not upstream useful at all. For instance, be able to have another set of translation for menu entries in the GNOME panel. And I guess almost all distro has a way to overwrite translation in the desktop file.

But for upstream, there is no point. Because upstream, the translation is in the desktop file. So that's one example of one feature which is not useful for upstream but useful for almost every distro.

To give a complete example on that, we have a patch which is shared by Vandiva, Ubuntu and Apponsusi for that. It's the same patch but it's not upstream. For menu projects?

For? For all the projects? What do you mean? So the idea that... Can we talk about that later because I don't have a lot of time left? The basic idea that distributions need to update the translations easily.

And they don't want to send an update of the desktop file. They want to use a PO file for that. And upstream doesn't care about this way. That's all. I just wanted to ask the upstream people we have here. What do you think about the idea of having a deep branch for all distributions which have a patches?

Do you think it makes sense? No. Come on, come here. I can shout. Yeah, shout. I did that package kit and I had an OpenSUSE branch, Fedora branch. And it worked really well for a few weeks and then nobody started using it. So it never got replaced.

So I think it worked for a little bit but then the distros just kept doing their own thing with spec files. So I think it works well as an idea but maybe not in reality. So maybe the issue there is that the tools we are using for RPM are not really well integrated with Git. Maybe.

I think it can only work if it's automated. It has to be automatically put back. It would certainly be useful to have that sort of thing. I tried it on LVM, my project for a while. But it was just unmaintainable unless it could be automated.

Okay. I think we have only ten minutes left. Eleven. Fifteen? Yeah. I have two things I wanted to discuss again. Sometimes upstream we are doing some big changes like the migration to GVFS, the GDN to 20 versus GDN to 24 which was completely different.

And moving ATE-SPI from COBRA to DBAS. And those changes have a high impact on distributions. And sometimes distributions don't understand why we are doing them because it's not stable yet.

So for example in the GDN case, the new GDN was not adopted by quite a few distributions for a long time. So I'd like to know how people feel about that. How we can improve the situation there.

Didn't happen only once. Not always but from time to time. So it's something that would be nice to fix and to have a good solution for. I'm sure that Fred would like to comment on GDN. What do you think?

Nothing. We are all happy with the big change that GNOME is doing and breaking everything for users. Well, the other people are happy. I think that the other distributions are not used.

Like in the GDN case, they are not using the software because it's not working for them. So first of all what we did for GDN is when GNOME 2.24 went out, we stated that there is a new GDN.

It's completely different. We think it's working relatively well but if you want stability you should use the old one. So it was kind of documented. But still people were not really happy with that. So maybe there's no other way to do it. So I think that if it's documented and if somehow the GNOME are aware that those are big changes

or things can go out of control. If they say, look, we are trying to push the Fedora for example, or we try to push it as an official just to get more feedback but you can still stay with this tool.

And if using GDN, the old branch was usable and not breaking other things in the new GNOME, I think that's fine. Yeah, but it only works for leaf package.

It only works for leaf package like GDN. You can replace new GDN by old GDN. But GVFS or ATSP, it's becoming a little harder when it's really deep in the stack.

So how do we manage that? The same question will happen with GNOME Shell. If we start to integrate GNOME Shell inside the new application, then this version may be done more or less. So I'm sure a lot of people didn't hear but what Xavi said, that we're going to have the same issue with GNOME Shell.

If people start to migrate applications to integrate with GNOME Shell, maybe the applications won't be working fine without GNOME Shell, which might be an issue. And then we added a new LE which is making big signs. Who cares? What do you mean?

It just means that basically as any other application,

so you shift on all those applications until your users will start explaining because you're not shaping the latest and greatest leading edge. And you will be forced to use it.

I know I understand it's problematic but upstream perspective is we cannot stop developing because suddenly we need to cover a stability issue

that downstream might have. Otherwise we have stagnation. We cannot do anything else. So I think I more or less agree with you. But I think the main issue there is that if you decide to stay with the old empathy, for example, it will not be maintained anymore.

And that's the issue people face. For example, if you look at GNOME Polar Manager, and I'm sure that he will look at me, ReachOut did a good job when he moved from hell to device kits. He just kept maintaining the old branch of GNOME Polar Manager for a while. And that was really good for distributions.

Absolutely. And if I'm not saying that, I'll take it.

Sure. I agree with that. Deep module life, you really need to get ggfs really working nicely in Nautilus.

Nautilus happened at some point. So for maybe one year there was a real mess in Debian at least because Nautilus was crashing and so on. Because it had moved partially to ggfs, but some other stuff wasn't working with ggfs and it was a mess.

So if we want to push GNOME Shell support in some other stuff, we really need GNOME Shell stuff to really work well. Because of that, it's going to be an image. So I guess the issue upstream there is that

if you want to make sure that ggfs... So in the ggfs example, if you want to make sure that ggfs and Nautilus are working fine, we need to deliver that to users. Else we wouldn't be able to know that it's not working fine.

In a yearly basis. No. Is it really working fine? I think it's a difficult topic. That's the kind of discussion I want to have with that. We came back with the Nautilus upgrade.

We had GNOME 2.24 and Nautilus 2.20 or whatever. So it wasn't a big deal, except we didn't have a new Nautilus feature and so on.

But it was stable. The distributors need to decide what version they want. A really stable system. And that is what Dell ended up with. Just to move on quickly since we have only 5 minutes left.

Or 4 now I guess. I wanted to quickly discuss the impact of GNOME 3 for downstream. We've started talking about GNOME Shell. I've written some stuff there. Just some crap if you can read that. But I want to know if downstream people are aware of how GNOME Shell will impact them.

If it's going to be an issue for you. If we need to change some stuff upstream for the GNOME 3 efforts. Or whatever. We want feedback on that. Shout please. I think a lot of people are scared shitless about applets. Applets? Yeah.

But they've got code that works. They've got a UI that they like. And there's no way to display the applet with GNOME Shell. So do you think that the plan of having GNOME Shell still available for use if people don't want to use GNOME Shell is enough for that?

Or it will not be actively developed. But it will be maintained. At least for a bit. Like it was in the past. Any other comment on that?

GNOME Shell is something that other applications need to integrate inside. If it's just a standard application that you install that distribution can decide. But if other applications start to integrate some technology from GNOME Shell

inside the application then it will be a choice to keep all GNOME on the GNOME 3. And nothing in between. So you're a bit worried that as upstream that As upstream I'm a bit worried that upstream continue with GNOME 3

and the distributor will just keep back GNOME 2. Which means more maintenance for you of all stuff? I don't care. That's GNOME upstream. And that's the next point. I don't understand how GNOME stream says

we maintain that distribution for three years. I mean, nobody maintains that. Upstream will never maintain any application for three years. Well, we kind of do for security bugs, but that's all. Yeah, well, people will hear you. Maybe not from Betty, but...

Okay, so... I'm running out of time. So if you want to discover that please come and talk to me or you can talk to any of the real estate people. We have Andrej Olaf there. We have Federik also. So we have a lot of people.

Don't hesitate to come and talk about that. As upstream, we need feedback on that kind of stuff. Thanks everybody.