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

Nautilus 3.24 – The changes

Another release of GNOME and Nautilus is coming, 3.24. As we have been doing for every release I will explain the changes that have an impact on the users and explain the reasoning behind them, and also a brief look into what we worked on this release.

User changes

Accessing root files – The admin backend

Since Nautilus was created, if a user wanted to open a folder where the user didn’t have permissions, for example a system folder where only root has access, it was required to start Nautilus with sudo.

However running UI apps under root is strongly discouraged, and to be honest, quite inconvenient. Running any UI app with sudo is actually not even supported in Wayland by design due to the security issues that that conveys.

So now we put a gvfs backend (kudos to Cosimo Cecchi) and we added support in Nautilus to open folders and files with no permission to access then conveniently into Nautilus itself. Now if you try to open a folder that requires special permissions it will ask for the root password with a dialog and once provided it will allow the user to navigate them without needing to restart the application or opening a new instance. The password is saved with a timeout so you can use access the file for some time, as is common with PolKit.

Also this allows to use Nautilus to access these files when using Wayland.

Here’s a demo how it works:

Operations button

Two releases ago we introduced a new way to handle operations in Nautilus, using an integrated popover rather than a separated window. We also added a button that shows a pie chart with the completion progress of the operations.

One issue we faced is that this button was not visible enough when an operation started, making the user think nothing was happening and the operation didn’t actually started.

For that we added an animation that makes the button shine, but seems that was not enough and after going back and forward through some solutions we end up showing the operations popover when and operations started, which is the last resort we could go with.

This is by far the least ideal solution, since it kinda disturbs the user and makes them dismiss the popover in every window (because where do you show it? only in the source of the operation? only in the destination? only where the user is looking at? everywhere?)

So we created a new animation that tries to catch more attention, and we will like to receive some feedback on it. Here is a demo:

And so far we didn’t add any user change more, so it should be a good release for those that like stability.

Nautilus desktop works on Wayland sessions

Thanks to Florian Mullner, he came up with a simple but working solution. Now you can use the desktop when in a Wayland session. Keep in mind this requires XWayland, and it’s backported to 3.22 too.

What we have work on

Flow box view

As you may know, the views in Nautilus are quite old and on the technical side they lack the most basic modern stuff, due to it’s custom implementation. For more than 2 years we have been working on allow a new view based on GtkFlowBox to be created.

Issues with current implementation are:

  • It’s not using gtk+ widgets or containers. This is by far the most important issue:
    • Any change or new feature  requires a whole “widget alike” object creation.
    • We cannot use any of the gtk+ widgets technology, including the gtk+ inspector or CSS
    • We cannot really create new visualisations like a placeholder for when copying files with some progress information or showing tags for files or any smart feature you could think
    • We have to maintain a big amount of code that Nautilus shouldn’t. This is widget work from gtk+
  • Spacing between items is not dynamic
  • Selection of items modify the visual of the picture, videos, icons with a blue overlay
  • We cannot have several zooms without making the view unusable.
  • The view and items “jumps” while it’s loading the files inside, making effectively useless to use Nautilus while the directory is being loaded.

This work it’s without hesitation the hardest and longest that Nautilus have faced for years. It required the desktop to be split from Nautilus, it requires modification in the most basic level of the code, porting to new technologies, etc.

Unfortunately, even if we managed to make all of this work, due to its performance issues we cannot switch to GtkFlowBox yet, and more work is required both in Nautilus and gtk+.

However I’m happy to announce that on the Hackfest we did last Novermber we decided to push forward this as a optional view to be able to iterate on its implementation and open the door for contributions from contributors and GSoC projects on it. This work is an experiment in several ways, not only in the technical part but also in the views itself and the code design. We will iterate on the feedback and code to make it shine before making it the default view. The same will apply to the list view once the icon view is ready.

This experimental view is now optionally checked as a gsetting called “use-experimental-views”. It’s not yet in the user preferences because it’s not in a usable state and it’s not intended to be used by nobody other than developers contributing to Nautilus.

Probably most of you already saw how this looks like on some of my posts in social medias almost a year ago. The state now is much better, here it is:

What did not make it into this release

You can take a look at the roadmap of Nautilus to see that most of the items I planned for this release were not implemented. Instead we implemented two different ones, the admin support and the new icon view.

This is expected, we decided a year ago to do a “tick-tack” release pace. Than means, one release with a lot of new changes and one with stabilisation and improvements in mind, and we kept that promise. We needed to stabilise and improve the new features, like the batch renaming and the decompression support, that we added last release.

So actually there are the same items that couldn’t be included and were mentioned in the previous release blog post.

The reasons this time are different. For the path bar, it was mostly because of the work in gtk4. We don’t want to have different path bars in gtk file chooser and Nautilus. So I would say we need to port Nautilus to gtk4 before committing the new path bar to gtk+. And that requires more work, and to gtk4 to stabilise a little.

For the action bar, was mostly because we need more design time on it. The difficulty in this project is not technical, but design wise.

You can look more details and bug fixes in the NEWS file.

Hope you enjoy the new release! As always, feel free to give any feedback or ask any questions in the comment section of this blog, be constructive please 🙂