IMPORTANT: GitLab mass migration plan

I know some fellows doesn’t read desktop-devel-list, so let me share here an email that it’s important for all to read: We have put in place the plan for the mass migration to GitLab and the steps maintainers needs to do.

Read about it in the email sent to the mailing list.

PD: What a historical moment, isn’t it? 🎉

GitLab + Flatpak – GNOME’s full flow

In this post I will explain how GitLab, CI, Flatpak and GNOME apps come together into, in my opinion, a dream-come-true full flow for GNOME, a proposal to be implemented by all GNOME apps.

Needless to say I enjoy seeing a plan that involves several moving pieces from different initiatives and people being put together into something bigger, I definitely had a good time ✌️.

Generated Flatpak for every work in progress

The biggest news: From now on designers, testers and people with curiosity can install any work in progress (a.k.a ‘merge request‘) in an automated way with a simple click and a few minutes. With the integrated GitLab CI now we generate a Flatpak file for every merge request in Nautilus!

In case you are not familiar with Flatpak, this technology allows anyone using different Linux distributions to install an application that will use exactly the same environment as the developers are using, providing a seamless synchronized experience.

For example, do you want to try out the recent work done by Nikita that makes Nautilus views distribute the space between icons? Simply click here or download the artifacts of any merge request pipeline. It’s also possible to browse other artifacts, like build and test logs:


Notes: Due to a recent bug in Software you might need to install the 3.28 Flatpak Platform & Sdk manually; this usually happen automatically. In the meantime install the current master development Flatpak Nautilus with a single click here. In Ubuntu you might need to install Flatpak first.

Parallel installation

Now, a way to quickly test latest works in progress in Nautilus it’s a considerable improvement, but a user probably don’t want to mess up with the system installation of Nautilus or other GNOME projects installation, specially since it’s a system component. So we have worked on a way to make possible a full parallel installation and full parallel run of Nautilus versions alongside the system installation. We have also provided support for this setup in the UI to make it easily recognizable and ensure the user is not confused about what version of Nautilus is looking at. This is how it looks after installing any of the Flatpak files mentioned above:

Screenshot from 2018-03-19 21-35-41.png

We can see Nautilus system installation and the developer preview running at the same time, the unstable version has a blue color in the header bar and a icon with gears. As a side note you can also see the work of Nikita I mentioned before, the developer version of the views now distribute the space of the icons.

It’s possible to install more versions and run them all at the same time, you can see here how the different installed versions are found in the search of GNOME Shell where I also have the stable Flatpak Nautilus installed:

Screenshot from 2018-03-19 21-37-24

Another positive note is that this also removes the need to close the system instance of the app when contributing to GNOME, it was one of the most reported confusing steps of our newcomers guide.

Issues templates

One of the biggest difficulties we have for people reporting issues is that they either have an outdated application, the application is modified downstream, or the environment is completely different as the one the developers are using, making the experience difficult and frustrating for both the reporter and the developer.  Needless to say all of us had to deal with ‘worksforme‘ issues…

With Flatpak, GitLab and the work explained before we can fix this and boost considerably our success with bugs.

We have created a “bug” template where reporters are instructed to download the Flatpaked application in order to test and reproduce in the exact same environment and version as the developers, testers, and everyone involved is using. Here’s part of how the issue template looks like:


When created, the issue renders as:


Which is considerably clearer.

Notes: The plan is to provide the stable app Flatpak too.

Full continuous integration

The last step to close this plan is to make sure that GNOME projects build in all the major distributors. After all, most of us are working both upstream in GNOME and downstream in a Linux distribution. For that, we have made a full array of builds that runs weekly:


Which also fixes another issue we have experience for years: Distribution packagers delivering some GNOME applications different than intended, causing subtle but also sometimes major issues. Now we can point out to this graph that contains the commands to build the application as exact documentation on how to package GNOME projects, directly from the maintainer.

‘How to’ for GNOME maintainers

For the full CI and Flatpak file generation take a look at Nautilus GitLab CI. For the cross distro weekly array additionally create an scheduled pipeline like this. It’s also possible to do more regularly the weekly array of CI, however keep in mind the resources are limited and that the important part is that every MR is buildable and that the tests passes. Otherwise it can be confusing to contributors if the pipeline is failing for a one of the jobs and not for others. For non apps projects, you can pick a single distribution you are comfortable with, other ideas are welcome.

A more complex CI is possible, take a look at the magic work of Jordan Petridis in librsvg. I heard Jordan will do a blog post soon about more CI magic, which will be interesting to read.

For parallel installation, it’s mainly this MR for master and this commit for the stable version; however there has been a couple of commits on top of each, follow them up to today’s date (19-03-2018).

For issues templates, take a look at the templates folder. We were discussing here a  default template to be used for GNOME projects,however there was not much input in there so for now I imagined better to experiment with this in Nautilus. Also, this will make more sense once we can put a default template in place, this is something GitLab will probably work on soon.

Finishing up…

On the last 4 days Ernestas Kulik, Jordan Petridis, and me have been working trying to time box this effort and come with a complete proposal by today, each of us working in a part of the plan, and I think we can say we achieved it. Alex Larsson and other people around in #flatpak provided us with valuable help. Work by Florian Mullner and Christian Hergert were an inspiration for us too. Andrea Veri and Javier Jardon put a considerable amount of their time into setting up an AWS instance for CI so we can have fast builds. Big thanks to all of them.

As you may guess, this CI setup for an organization like GNOME with more than 500 projects is quite resource consuming. Good news is that we have some help from sponsors happening, many thanks to them! Stay tuned for the announcements.

Hope you like the direction GNOME is going, for me it’s exciting to modernize and make more dynamic how GNOME development happens, I can see we have come a long way since a year ago. If you have any thoughts, comments or ideas let any of us know!

Nautilus team grows – It’s my pleasure to welcome Ernestas Kulik as co-maintainer

Becoming a maintainer of a FOSS project is not easy. It requires much more than just code skills. It’s about responsibility, product management, vision, community and hard work in long-term.

Becoming a maintainer of a FOSS project like Nautilus is even harder, it requires a sense of what being used by millions of people and delivering to business entitles. It also requires understanding the complexity of a file manager, and the old code that lies behind.

Now, becoming maintainer of a project that already has a maintainer working full time on it… that’s a different level.

Ernestas started contributing more than 2 years ago as a community member on his free time. Did major code work like porting Nautilus to Meson, make Nautilus work on Flatpak, improved search, improved operations, took the lead on fixing all deprecations (we had many!), worked on a prototype for a new cache/operations backend, dig into other libraries deeper on the stack to fix something that was visible in Nautilus, and many other things. What was most noticeable is the quality Ernestas strives for in all these contributions.

However, the above would make him “just” a good software programmer, the important part that makes him a good maintainer were other actions. Ernestas took the lead on newcomers bugs review/assignment, took the lead on legal matters like the GPL3 vs GPL2 issue we had with extensions, reviewed code from other contributors (including me), worked without dilation on critical issues in a timely manner, worked on tasks important to our vision, engaged in bug reports with good communication, helped with project direction, considered all sides and the big picture when taking decisions and last, all of this with excellence. If you ever wondered what someone has to do to become a good maintainer/co-maintainer, here’s the answer.

So without more dilation, welcome Ernestas in his new role as co-maintainer, go on IRC and congratulate him 🎉

Nautilus desktop plans

Hello all,

We have been discussing our plans with the desktop part of Nautilus for quite a bit of time and in this blog post I’ll explain them.


Nautilus had have a feature called “the desktop” which adds icons on the background of the user workspace, similar to Windows.

The desktop was disabled for the default experience when GNOME 3 came out now 6 years ago,  and so far has been mostly unmaintained. I spent around 3 months of work two years ago to try to save it somehow and did a rearchitectural work  to try to separate the desktop from the Nautilus app so it won’t affect Nautilus development, and while it achieved some degree of separation, it didn’t achieve its main purpose and unfortunately brought even more problems than we had before. Now it has got to a point where the desktop is blocking us deeply in basically every major front we have set for future releases.

Also we notice that users rightfully have expectations for the desktop to work decently, and we acknowledge this is far from the reality and we are aware that the desktop is in a very poor state.

If you are interested in more technical details of the issues with the desktop implementation you can read them here.

With these points at hand that have accumulated over the years, we are at the point that we need to remove the desktop code inside Nautilus for Nautilus 3.28 to move forward with Nautilus development. You can check the branch with the removal work here, if you look you will see that the desktop is composed by more than 10.000 lines of code given the complexity to create it with the technologies that were available in 1999 (yes, the code is that old :)).


With removing the desktop code from Nautilus we have considered these three options, keeping in mind that the ability to have icons on the desktop can be provided by other projects than Nautilus:

  1. Fork Nautilus desktop, one project being the desktop and the other being Nautilus app. This however doesn’t fix anything at all, the issues will still be there and I’ll be very sad for anyone that has to maintain it.
  2. Use Nemo desktop. This is, as of today, a more featureful desktop than the one in Nautilus, so probably it’s the best short term solution. It however has similar problems than the ones Nautilus desktop faced. You can read how to install it here.
  3. Make the desktop icons a Shell extension.


The best option to of those three to move forward is to integrate it in a GNOME Shell extension. Doing what nautilus desktop was doing in an app (Nautilus) while trying to be part of the compositor (GNOME Shell) was a big mistake, and it’s one of the major issues. It’s important if you understand some technical terms to check the issues we were facing to understand how we agreed to this proposal to be the best option. This is true even more nowadays with various technologies being more in the isolation, privacy and secure side (Wayland, sandboxing, etc).

A nice thing of doing a GNOME Shell extension is that it opens the path to a more dynamic desktop workflow, and the good news is that the prototype that we have in place already has fixed one of the oldest bugs we had in the Nautilus desktop, proper multimonitor support!

You can check the extension prototype here (very early prototype). While this extension is the way forward, the time I can spend on it is limited since upstream wise the desktop pattern didn’t make much sense for long time now. So I encourage anyone that knows JavaScript or wants to learn JavaScript and likes the desktop workflow to make it happen, I’ll be there for helping any contributor making code alongside and to expand on new ideas for the desktop workflow that those that like it have in mind. You can check few points that would be nice to have for a first release here. Ping me on IRC if you are interested on it.

Who will experience a change

For those using distributions with desktop pattern workflows (e.g. Ubuntu), I don’t expect anyone to be affected, if those distributions/projects derived from upstream design decisions based on their own design decisions, I expect they will hold into those patterns and provide a desktop workflow in one form or another.

If your distribution didn’t ship a desktop by default and you were using Nautilus desktop, you can check out the options proposed before to continue using a similar workflow.

Fruits of the removal

The question is, when are the fruits of the removal of the desktop going to be noticeable?

Thanks to the removal of the desktop code we are now free to move forward with the complete rework of the Nautilus backend for 3.28, probably the biggest rework ever done in Nautilus. This will allow heavy searches to not make the UI get stuck and to be resource balanced so you could do multiple searches at the same time, it will also provide proper thread handling, ability to pause operations, ability for performance stats (and finally being able to do performance improvements), easy tweak for operations resource balancing, and more.

Another major work that thanks to the removal of the desktop code we can move forward with is the new views that I talked about in a previous blog post. We won’t make it for Nautilus 3.28 since it requires gtk+ work too, but now we can continue improving it in the Nautilus side and hopefully for 3.30 we can finally move to the next generation of content views.

And finally, this also allows for Nautilus to be ported to gtk4. This is really good news in various fronts for Nautilus; hopefully gtk4 stabilizes a little bit more and we can port to it for Nautilus 3.30.


I want to thank Ernestas and Antonio to work on these big changes and the help overall with Nautilus!

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!