GitLab update: Moving to the next step

Hello community,

I have good news, after few meetings and discussions with GitLab we reached an agreement on a way to bring the features we need and to fix our most important blockers in a reasonable time and in a way that are synced with us. Their team will fix our blockers in the next 1-2 months, most of them will be fix in the release of 22th of December and the rest if everything goes well in the release of 22th of January. The one left that out of those 2 months is a richer UI experience for duplicates, which is going to be an ongoing effort.

Apologies for the blockage for those that regularly asked to migrate their project, I wanted to make sure we are doing things in the right steps. I also wanted to make sure that I get feedback and comments about the initiative all around in my effort to make a representation of the community for taking these decisions. Now it’s the point where I’m confident, the feedback and comments both inside and outside of our core community has been largely that we should start our path to fully migrate to GitLab.

So starting today we move forward to the next step, this means that all projects that want to migrate are free to migrate. I’m also coordinating with some core apps for a migration in the upcoming month (e.g. Documents, Photos, Boxes), with other core projects to be migrated once we have in GitLab the features we need (i.e. Software, Shell, Mutter), and more platform-ish core projects like gtk+, glib etc. to be taken their time to ensure their migration is smooth. All depends individually of the project and the maintainer, of course.

With this change comes other news: We did our first batch migration of 8 projects today, totaling 21 projects that have moved by now. Also, the Engagement team has started using GitLab for better tracking and collaboration with the rest of the community, don’t hesitate to check it out if you want to make publicity of some feature or if you want to collaborate!

To make the transition easier, I created a general documentation for using GitLab for GNOMER’s, check it out here (feel free to edit). If you want to help, get in touch with me or check out our task list. If you want your project to be moved, get in touch with me or create an issue like this one.

As always, I’m there for your questions and feedback. You can do so in this mail chain, in irc, in private messages to me or by filling issues in the GNOME infrastructure project. I just want to ask, please keep in mind that I’m doing this entirely in my free time, so be considerate, I don’t have unlimited energy 🙂

Also thanks to all that helped so far, specially Phillip, Emmanuele , Alberto, Andrea and the GitLab team.

Hope you enjoy the news and the work we have done.

You can follow the discussion in the desktop-devel-list of GNOME.


GitLab initiative – Short summary

Hello all,

Georges told me some people outside of our community asked about our GitLab initiative and that there is some confusion what the status is and that contrary to my belief, there is actual interest outside of GNOME. Since I guess people outside of our community didn’t follow our regular conversations, discussions and update reports in our GNOME mailing list for general desktop discussion,  I’ll do a short summarize.

Almost a year ago we started looking into alternatives to Bugzilla and cgit, and it became a long research, discussion and meeting with several parties and a few of us, Alberto, Allan and me, which then expanded to more people in order to give a different point of vision, like Emmanuele, Daniel, etc. All the research, work and reasoning we did and our eventual decision for a recommendation is written in our wiki page.

The actual status is that we are running a pilot program. The pilot program is a way to test GitLab in real life usage with real products, collect feedback, promote the usage and getting used to the tool by the GNOME community, and eventually to take a decision whether we migrate to GitLab the GNOME project as a whole.

Given the (social more than technical) complexity of moving all GNOME at once to a platform nobody of us used for GNOME projects, we decided to gradually move some willing maintainers and projects first, limiting the amount and the type of projects we migrate. In this pilot program, maintainers commit on a permanent migration to GitLab for the time being, to be aware of the issues we are dealing with, and to provide feedback when possible. When our tasks are done, technical issues fixed, current maintainers in the pilot program give a general positive feedback, community gets used a little bit more to the tool, and the upstream fixes we asked for are done, we will take the decision to move or not to GitLab GNOME as a whole.


Are there deadlines?

No. And at the same time, ASAP, which for a project of our magnitude is in the range of months.

What are you blocking on?

In tasks on our side, and in upstream issues. And of course, in our energy and time.

Can I help?

Yes, feel free to ping me for those task on our side.

Where is this hosted? Which projects moved?

You can take a look on our GitLab deployment.

Who is the person of contact/Who is taking most of the decisions?

Nowadays mostly me, with our sysadmin Andrea on the sysadmin side. I’m trying to represent as much as possible GNOME as a whole, and I’m focusing on trying to evaluate how much the community is happy with it or what has more or less priority. Obviously, this is the hardest part.

When will a decision be made? What are the requirements for that decision to happen?

This is more a social problem than technical. It needs to settle down on our community and is difficult to quantify. So no deadlines, and no hard requirements. As mentioned before, I’m trying to evaluate the consensus of the community and the overall status, and I’ll communicate to the GNOME community when I think a decision can be made and what I believe we should do, and get feedback at that point.

What’s the worst case scenario? How likely is that to happen?

The worst case scenario is that we decide we don’t move to GitLab as a whole, and then I expect the projects that migrated to GitLab to be migrated again to Bugzilla and cgit. There are other possible scenarios, but I don’t consider them for now. At this point this  scenario is unlikely to happen, since the initiative is going better than expected and I receive more queries to move projects that I can manage or that I consider we should migrate for now, the feedback in overall is positive and there is excitement in core maintainers and products to move to GitLab.

It’s true we have some blockers upstream that we are tracking in our instance as mentioned before and that they need a solution to move forward, but I’m confident with our meetings and discussion with GitLab eventually they will be fixed.

I have feedback/other questions/issues

General feedback can go to our wiki page or for public discussion. You can also contact me on IRC as csoriano in #gnome-hackers at or send me an email to for direct contact. Issues can be reported in our GitLab itself.

Empowering individuals of the community – The board takes action

(Disclaimer: I’m speaking as a single director of the board, wording and specifics could be different than written here as this post has not been reviewed by the board.)

(Disclaimer 2: Some parts of this blog post were covered by Allan’s and Alexandre’s blog posts.)

This blog post is intended for GNOME Foundation members or people interested in part of our budget management. I have good news for you, the board has decided new policies to empower the individuals of our community!

Budget for individuals

For long the board have been the holder and decision making approval of all (big exception with travel committee) the GNOME foundation budget. Of course the community trusts the board to manage the budget as the board believes is better for GNOME, but the board thinks GNOME members doing important work for GNOME are also to be trusted, and we need to empower them however we can.

In order to achieve this, the board has approved a new policy. Now, individual GNOME members can be holders and managers of budget!

That means, as a single GNOME member you can be given an allocated amount of cash to be managed and spent in the way you believe is better to progress the goals of GNOME (after budget and goals are discussed and pre-approved with the board), and you will be able to spend this amount of money per year without need to discuss again with the board, or any other approval. That could include things like buying items or food for a meeting, promoting other individuals (a wild idea, for example to bring an expert to a workshop), promoting small events with marketing, etc.

A concrete example: You could mention to the board that you usually host workshops for newcomers and workshops for translators in your city. Then the board allocates 500$ per year to be managed by you for this purpose. You don’t need to discuss or pre-approve anything else, you are free to spend that budget yearly with that intention indefinitely, we will just look at the reports to see how things are going or do some meetings to sync with you.

I’m honestly excited imagining all the possibilities that this brings to members of GNOME, and how much that empowers the individuals of our community. Wanna know more? Read the budget policy for individuals.

Delegated decision making

We talked about budget management. But the board is also responsible of most of decision making at GNOME. Marketing, events, conferences, sponsorship, hardware requests, the software that defines GNOME, legal inquiries, and many more. However, we believe members of the community should be trusted to also take part of some high level decision making of GNOME.

We want the community to take leadership roles, influence where GNOME goes, and give them voice and decision making power. We want more integration with more people of the community. In short, we want members to take the role of the board in specific topics. A step closer to the board itself.

So the other big decision is that the board have agreed on expanding this concept, reach more community members and promote new roles to take upon. To achieve this we have started drafting new committees with new members, an approach to be more in touch with our current and new committees, and brainstorm a way to make easier for members of the community to apply for these roles.

This is still not set in stone and we are looking for other ways that are not necessarily committees, or to make some committees more flexible & easier, but I hope you are ready because we will write over the next weeks news about this and opportunities for being part of them!

Thanks the board and foundation employees

As a selfish last section, I want to thanks all the members of the board and employees. This wouldn’t be possible without their energy and tireless willingness. These discussions were part of our hackfest at Berlin; honestly, the hackfest was hard and draining, but it was productive and necessary. It was the first time in the history of the foundation that the budget was approved at the start of the fiscal year, so I’m proud of what we have achieved. Many more discussions, decisions and policies took place, you will heard about them over the next weeks.

Like what we did? Let us know!

Hope you like the work we have been doing, the policies and ideas we came up with to empower you as part of GNOME. I also hope you now have a grasp of what the board does and how it can impact our community.

If you have any question, let me know here, irc or by email, I’m looking forward to know what you think. You can also always contact the board at, don’t be afraid of it, really!


PSA: All newcomers apps build again

For some time a few of our newcomers apps were not building due to an issue with Builder and Flatpak.

Finally the issues are fixed, in Flatpak 0.9.10 and in Builder stable (that you will have from Flatpak if you followed the Newcomers tutorial). Only thing needed is to update Builder and make sure Flatpak is at version 0.9.10.

If your distribution has already latest Flatpak (e.g. Fedora 26 or newer) and GNOME Software 3.24 (e.g. Fedora 26 or newer) you simply need to go Software, click the refresh icon, wait to download updates and then click “Update all”.

If you want to do it in the command line:

flatpak update
flatpak update --user

And to update Flatpak in Fedora

sudo dnf update -y

Apologies for having broken builds of Newcomers apps, we definitely need a way to ensure Builder integration with apps are tested regularly in the future!

Feel free to report if something is not working as expected in our newcomers channel.

Remember you can start contributing to GNOME apps and technologies in a few minutes following our newcomers guide, give it a look!


Hello all!

One thing I enjoy to do when visiting a new city is to visit corners that are not touristic to not miss the “real” culture that you can experience in non-touristic places.

Not only that, but we all know we are used to eat more than usual when traveling, and we don’t keep doing some of our good habits.

For that reason, every GUADEC I try to put together some people and we go running for 5-7 km to different places every morning, with optional exercices once finished. It’s exercice to chill and enjoy, so no worries if you are not in shape.

I created a Riot room that you can access (even as a guest user) through the web, phone, etc. to discuss where we will meet and where we will go

So make sure to bring your sport shoes, don’t be lazy, and join! 😉

Clarification on a recent security flaw on a thumbnailer

Recently a GNOMEr pointed me to a blog post from someone that found a security issue with a thumbnailer called gnome-exe-thumbnailer which tries to thumbnail MSI files and parses VBScripts using Wine, and unfortunately it allowed execution of random code.

How thumbnailers works is that we allow libraries to register as thumbnailers to be used by our generic thumbnailing framework, and although they are out of process, they are not sandboxed. You can understand this issue as if it would be a plugin that has a security flaw.

This would have been a regular CVE in gnome-exe-thumbnailer and world would have move on, however the problem came when the author pointed out the fix was “Don’t use GNOME Files” and the framing of the blog post was, from my point of vision, misleading.

In reality this affect anyone using this thumbnailer, including MATE, XFCE, etc., the project has nothing to do with GNOME, we have never heard of it, and some distributions don’t even have it in their repositories (in this case I checked RHEL and Fedora and they don’t have it). I also find quite disrespectful towards whoever wrote that library to not raise a bug privately, and instead made a public blog post.

The CVE in question, named “Bad Taste” (with even a logo(!) of a wine glass) can be found here.

Does this affects me?

Probably not, since you would have need to install this library on purpose and also use a distribution like Debian/Ubuntu (so far what I checked) that includes it.

However be careful if you do since quite a few programs would use that thumbnailer, including Totem, Eye of GNOME, etc. and there is no way to disable thumbnailing on those (ironically Nautilus does allow to disable thumbnailing).

The fix

Uninstall gnome-exe-thumbnailer :). You can still use Nautilus.

Can GNOME do something?

Yes. We can sandbox thumbnailers (with the same technology as Flatpak, called bwrap). Work is actually almost done over the last 6 months, and hopefully will be merged and relesed soon.

This is also a reminder to all of us that we should move to a world of more sandboxed applications and plugins. This is actually one of the top priority items for us. In that front we have been working hard and pushing as much as we can with Flatpak to create a world of sandboxed apps. If you are interested on the security side of applications, you are welcome to help us shaping the future of it.

In conclusion, it takes 2 minutes to contact any of us and verify your statements/blog post/tech news. Please do, before posting.

As a take away, grab this mojito🍹 and fix the “Bad Taste” 😉

The new contribution workflow for GNOME

Hello community,

I have big good news to share with you. You might know we have been working for years on materializing what we wanted the future of contribution to be, we did multiple iterations and we worked full time on our developer experience… and finally, I’m glad to announce, we achieved it, we have a new way to contribute to GNOME!

One image says more than 1000 words, the whole process of contributing to GNOME is as easy as you will see, all documented in the new newcomers wiki


No specific distribution required. No specific version required. No dependencies hell. Reproducible, if it builds for me it will build for you. All with an UI and integrated, no terminal required. Less than five minutes of downloading plus building and you are contributing.

Can you imagine how this changes the GNOME contribution story? We went from requiring either latest Fedora or Ubuntu, fighting dependencies and random issues, taking more than 80 modules to build just for contributing to a single app. It was a pain.

As an example, Nautilus with the previous tool and workflow took around 6 hours the first time if no issues were present. Now it’s 5 minutes, with no possible build issues (forgive exceptions in the rule 🙂 ).

I think we just opened a new world for contributors.

The work behind it

Of course, a change as big as this didn’t come overnight, this is possible because GNOME and sponsors put the time and resources on it, with rock-stars like Alex Larsson creating Flatpak and Christian Hergert creating Builder, working both for years nonstop in these technologies, with no short term benefit.

Finally the benefit is here, the future we imagined and shaped 5 years ago is coming together, and it’s shining.

Thanks a lot to the people involved, also specially Bastian Ilso for his guidance, design and writing of the new wiki guide.

Hope you enjoy all the work we did, I’m looking forward for your feedback and to fix the issues you may find (contact us in IRC in #newcomers). And soon, to have your first contribution with GNOME done 🙂


PD: Please follow the newcomers wiki to have it working, lot of work to make this happen was done in Flatpak 0.9.1, when Ubuntu 16.04 has 0.8.4 for now, so we say to use a PPA for have it updated. I tested thoughtfully in Ubuntu 16.04 and Fedora 25, and it works out of the box following the wiki making sure Flatpak is updated. Thanks all for the feedback so far! 🙂

PD2: I just realized I had a small error when doing the switch to the new wiki and the instructions for Ubuntu 16.04 and PPA got lost. Now it’s fixed, try again and tell us how it goes! 🙂

PD3: Cool video of Jono Bacon showing what Endless does with the same technology