It’s been two years since the last blog post, with all the changes in life and work, it deserves a blog post flush. From here above, stories come from a different background, different way of living and working, and different experiences.
And I believe this would be true for almost everyone 😉
Felipe Borges and me recently went to Akademy after a conversation between the two of us three days before the KDE conference that went like:
And so three days later we traveled to Wien to meet with the KDE community. On arrival, we were pleased by a friendly and joyful ambient on the pre-registration party, which had no registration at all! We were happy to know these issues don’t happen only at GUADEC.
I only knew from before Aleix Pol, the vice-president, Lydia Pintscher, the president, and Alex Fiestas, a KDE dev I would have paid to had him as flatmate when I was at university 😜. Fortunately, we started meeting all the people around in no time .
Shortly after revealing I was part of GNOME I was tagged widely as the “GNOME spy”, and that is not far from the reality! I was there to learn what they do better, and of course finding ways that we can collaborate.
There are other areas KDE does better because of not-easily-fixable handicaps at GNOME such as QT documentation being better than gtk+, etc. But! I also realized how much GNOME does better in some other areas, something you don’t realize until you see what other projects are doing.
There are three main areas that struck me as game changers.
There are other areas that GNOME does better just because of handicaps KDE might has such as not being default in most of well known distributions or being less enterprise-ready (work we do a lot at Red Hat for GNOME in order to comply with US regulations, etc.).
I tried to give my advice and offered my help on these areas from now on, as I believe what GNOME uses would benefit KDE and in the same way would benefit GNOME by using the same tooling as our colleagues at KDE.
Flatpak. Yes! Looks like KDE has a wide interest on use more and more Flatpak. Some aspects I could gather from them is that the community driven nature and FOSS stack of Flatpak aligns with the values of the KDE community. Seems they also appreciate the technical thought and technology behind that was put into Flatpak. Alex Larsson is truly an amazing dev.
However, they would appreciate the Flatpak community to proactively approaching KDE to help use Flatpak more, and it’s something I would like to see more too. I proposed to do a hackfest together to collaborate improving the usage of Flatpak and collaborate with the community as a first step. So hopefully there will be one soon!
Wayland. They really want to improve the Wayland status at KDE. At GNOME we have some (1.5?) developers working on it and at KDE they have one working on it. So I proposed to meet with the GNOME developers to share advice and see how the collaboration in Wayland freedesktop for new APIs such as screenshot, screen sharing, color picking, etc. can be improved. Hopefully soon we can all meet to discuss these out.
I also met and chat with Albert Vaca, the creator of KDE connect. He actually uses GNOME but only attends KDE events because he loves the community, which is quite interesting to me.
KWin maintainer Roman Gilg who I chatted with about Wayland and further collaboration between GNOME and KDE. Roman also tried to save me on Saturday for the lack of parties (I hope next Akademy there is a party on Saturday. GUADEC social events were amazing this year thanks to Ismael).
Slimbook CEO Alejandro López who I chatted with about hardware, OEMs and opportunities around that. Excellent and fun as always.
Ben Cooksley who is this amazing free time sysadmin contributor that runs the whole KDE infrastructure and we chatted about CI setup and funding.
The newcomers experience leader Neofytos Kolokotronis who is passionate about improving the newcomers on-boarding.
And last but not least, I interchanged with Aleix and Lydia valuable advice on how the board, community and funding is ran in both GNOME and KDE. I also ended having a passionate argument with Aleix (as always 😜) that ended up with a hug.
We have already some email threads and discussion on these ideas on the work, going to the conference is already paying off.
Overall, nice conference, nice people, and I’m thankful to all of you at KDE!
Thanks the GNOME Foundation for sponsoring both Felipe’s and my trip.
Hi all,
Today I have good news for “classic mode” users and those used to desktop icons.
As you might know, few months ago we removed the handling of desktop icons in Nautilus. As mentioned in the past, the desktop icons code was blocking at that point any further major development of Nautilus, and the quality was not up to our standards that we want to deliver.
The most important responsibility I have as (now one of the two) maintainer is to ensure the project progresses in its main goal, which is being an excellent file manager app. This includes building and maintaining a healthy community of contributors around, which I’m proud to have. I take these points very seriously, and as such, sometimes I have to take hard decisions to make sure this is achieved. When put into a position where either the project stagnates in its main goal and lose all interest from community contributors I have no doubt what is the path to go. And sometimes those decisions has to be taken shortly, after years trying to overcome the problem. Sometimes that happens when no others resources/time/people for providing a complete drop-in alternative are available.
This is also true for users, when put into the choice of having reliable file operations, search not blocking the computer, proper views, etc. the decision seems clear.
Good news is that this all is paying off! The gtk4 port of Nautilus is now almost ready, we are having a hackfest soon with gtk+ developers to plan putting the new views in Nautilus, the work on the reliable file operations and search is now free to continue, and we had put a testing framework that consolidates this effort. The community of contributors has also been working as ever, and the results are clear in the Nautilus 3.30 release.
For Fedora and RHEL we have had an option called classic desktop, where desktop icons and some shell extensions were enabled.
It’s useful to bring to those users an option that works better than what we had with Nautilus, so as part of that I spent my time at Red Hat working on providing this.
So here we are, I worked a lot lately in Nautilus and in the extension I prototyped few months ago to reach a point where it’s ready to enter a beta phase, now for everyone to use!
It has the regular things someone would expect. Some screenshots:
Things that are missing are renaming files popover and DnD to “paste into a folder”.
To try it out, you need latest Nautilus. Install from the nightly flatpaks following these instructions. Then you need GNOME Shell 3.28 and to install the extension from the extensions GNOME website. Then make sure to have development nightly Nautilus running and then in GNOME Tweaks enable the extension.
Note: For Fedora it’s needed to disable the “Fedora logo” extension, as it collides with the desktop icons.
Beta also means you may find some visible bugs, please report them. As I get more feedback I will change, remove, introduce stuff to make it ready for 1.0.
Also more importantly, merge request welcome! If you have a feature that would like to implement or fixing a bug or behavior, feel free to download the code and create a merge request in the extensions repository at GitLab. I’ll glad to review your code!
Thanks Antonio, Ernestas, Florian and Didier for helping with review, testing and planning.
Hello all,
It’s this time of the year again, a new Nautilus release is on its way to be delivered. This release has been increasing contributions and work done in a steady pace as it has been for the last years, which makes me happy as one of the maintainers of Nautilus. This release had around 140 major contributions (merge requests) including whole features, fixes and improvements. Against our willing, we have included more code than deleted by 3000 lines 😉
I will explain the most visible improvements and changes we have been doing as part of this 6 months effort. But first, a peek on how Nautilus 3.30 looks like:
We have been trying to improve the exposure of available actions and make them available for the list view and for touch devices for over almost 3 years, iterating on several designs. We finally came with a solution that we are happy with. As a result the user can now access background actions in list view such as creating templates or extensions like opening in a terminal.
We also implemented a less cluttered path bar and moved the search entry to the same place to give more place for the actual content, the user’s files. Lately, we improved the usage on small resolutions making Nautilus be able to shrink up to 530px. The result is the following:
As part of the new design, we also replicated the app menu actions to the hamburger menu so it’s easily accessible in multi-monitor set ups:
The end result feels definitely more modern and implements one of the most requested features.
Probably everyone is aware that the code in the icon view of Nautilus is from 20 years ago when gtk+ didn’t exist, so it does everything manually.
One of the most obvious limitations was how the space was distributed between icons, it was not distributed at all and there was always empty space at the end. In previous versions it looked like:
Fortunately we came up with a solution for this release, with these results:
While the goal is to eventually move to a more modern code and use a proper gtk+ widget, this improves the situation until we can achieve that major goal.
Thanks Nikita Churaev for this work!
When Nautilus had desktop icons we used to manage desktop files in a special way since the desktop was used as a way to launch applications. Last release the desktop was no longer part of the Nautilus code, so we could finally reconsider having desktop files as a special file to be launched or not.
The special treatment of desktop files had several problems, including security concerns (we had a CVE last year!) . Unfortunately the way we had to handle them was a blocker for the major rework of file operations that we are planning. This work will allow proper handling of files operations making them faster and secure.
The .desktop files are now treated as normal files: their real file name is shown and they open as text files in applications like GEdit. We leave their graphical edition to more featureful tools like Alacarte. We can provide replacements for some of their uses (you can provide use cases in the ticket). This goes with the vision of having a canonical path for trusting binaries and permissions rather than rely on Nautilus for such a delicate action.
One of the major work this release has been around making the whole feedback cycle of Nautilus development shorter and make as easy as possible for everyone to test any change we do to give feedback even before the work is implemented.
As part of this, we have improved the experience of Flatpak with Nautilus, created a whole continuous integration (CI) and continuous delivery (CD) system with GitLab and Flatpak that automatically creates an app bundle, so anyone can install any work in progress of Nautilus with a single click.
Going to any merge request and clicking the “View app” button will install a Flatpak app bundle where you can try the work in progress. A nightly of Nautilus that updates every day is also available in the GNOME Nightlies.
It has proven already successful with the toolbar redesign helping us getting early feedback and iterating on it. We hope that from now on everyone try the nightlies and engage with us on Nautilus development by either providing feedback, designs or contributing code.
Also, maybe it will come as a surprise, Nautilus didn’t really have automatic testing. To improve the situation we have invested 3 months on providing automatic testing to Nautilus. Now we have a full framework and batch of tests in the most critical parts like file operations and search. Automatic testing will improve stability and will avoid regressions reaching the user and has already made us find and fix several issues.
Thanks Jordan Petridis, Ernestas Kulik and Alex Fazakas for this work!
We have implemented a new search engine for faster results of user files that have been recently used. This will be an improvement specially for users in Ubuntu LTS that don’t have tracker installed and were used to search for files in the overview in Unity.
Thanks Marco Trevisan from Canonical for this work!
We have also work in many more details.
We have redesigned and added an information bar in case only the current location is being searched:
A detail to spot here is that Nautilus has the FTS feature which also takes into account the actual content of the user’s files for wider and better results.*
* Not available in Ubuntu
Advanced tooling for partitions and external devices can now be accessed easily in the properties window. Thanks Rahul Verma for this contribution!
Nautilus now supports popping context menus in touch devices by long pressing a single file or the view itself. This is another step on making sure Nautilus can be used with touch devices, as they become more relevant specially for business like design, sales, marketing and finances. Thanks Jan-Michael Brummer for working on this!
I hope you will be glad of this release, it has been a continuous effort of several people during 6 months, and we think it pays off!
While we fix the issues this new code introduces, we are already planning about the work for the next release. So what’s to come?
Ernestas Kulik is working (and sweating it) the port of Nautilus to gtk4. We have created a Flatpak nightly for testing, however it’s still very early and most likely will have major regressions. Our hope is to introduce gtk4 for Nautilus 3.32, we will announce the ready status for testing in the upcoming next 3 weeks.
Apart from that we have many other things, we expose our vision and planning for the project in GitLab. So go ahead and check what is going to come and provide input ahead of time to help us steering the project, check out the short term vision and planing, the long term vision and planing and lately, the vision and planning with possible user impact.
Thanks to all the contributors!
As part of Ernestas Kulik work on porting Nautilus to gtk4 he has created a tagged entry widget to replace libgd tagged entry and eventually upstream to gtk proper. To give easy testing he created a Flatpak file for building a simple app with this widget, which serves as an example of how to create a simple app with gtk4 too.
So feel free to grab the YAML Flatpak file and start to test out gtk4 with your toy applications!
Hello all,
In a previous blog post I asked feedback about adding an always visible action bar to Nautilus that integrated the floating bar info too.
It was very useful, as most of you confirmed our suspicions that it was too heavy, so we researched for a better solution for the goals we had: Make actions more discoverable, have good touch support and better pointer accessibility (not being able to access actions in list view anyone?).
Multiple people participated with constructive, well written and excellent feedback. Even more, they even provided high quality mock ups with ideas, to the point that I’m genuinely surprised.
So the goal of this post is for you to help me figure out what went well to have this constructive interaction! I have several factors in mind, could you share your thoughts?:
Feel free to pick several of them or add more factors if those were the important ones for you (try to write down which one was the most important). I’m looking forward to repeat what was good for you all to participate in our next ideas. You can share your thoughts here in a comment or contacting me on irc.gnome.org in #gnome-hackers or #nautilus as csoriano.
Thanks!
PD: Feel free to try the solution we came up with and share your feedback & ideas in irc or in the issue.
Hello all,
I have been trying to improve our development experience by putting things together and create processes for our most common tasks taking advantage of the automation and features from GitLab and other technologies.
Today I’m going to propose the workflow for project & release planning for individual projects and for GNOME as a whole in the least time-consuming, most automatic and simple way I could come up with.
It’s my hope that this proposal will improve our contributor experience, reduce time spend on tracking issues, improve communication between teams such as design and engagement, increases exposure for PR, and finally, shorten the feedback & review cycle.
Workflow from written plan to implementation in individual tasks in individual projects. For example Nautilus does nothing, and others like ToDo, Calendar and Boxes use the Kanban workflow. The proposal written here is for the higher & overview levels.
Only three, but important:
One thing that applies to all of us is that writing plans down feels heavy. However it’s usually not about writing per se, it’s more about thinking what the format should be, what you actually need to write, etc. — Formalizing a plan is not easy.
To alleviate that, I created an issue template on GitLab to be used when you need to set up a plan. Copy it inside your project as “.gitlab/issues_templates/Epic.md”. It’s called “Epic” as a term that comes from Agile development. An Epic is a plan/task that goes across releases or development phases. Tasks that are achieved in one release are also fine, given our long 6-month cadence.
However, what’s important about epics it’s their meaning. They mean that the task fulfills three things:
Specifically, they are not moon-shots. e.g. Improving Nautilus performance is not something that is well scoped and it doesn’t have a end date, therefore doesn’t fit as epic. In doing so, we avoid ideas that are unrealistic and also we don’t set the wrong expectations to other contributors, other teams, users and even more important, to ourselves.
You can see how it works for Nautilus in these two examples, adding a testing & performance framework & adding an action bar. And also we can consult epics across GNOME by an assigned label that I created for the GNOME group. It’s possible to see that the planning worked well for evolving the action bar design to something completely different than the original proposal thanks to the feedback and design contributions from several parties after exposing our plans in a easily reachable way.
With this we can answer what is the vision and priorities for GNOME projects individually or as a group.
It’s a fact that we cannot really handle all the issues that are reported to our projects, to the point navigating them stop making sense. Not only that, contributors & potential contributors usually don’t know on what to work or the priorities we have as a project. Or even worse, contributors providing patches that are not a priority so they are languishing for months with no review. I’m pretty confident to say that we lose contributions by not having clear plans.
So how about flipping the approach and pick the tasks/issues that we really care about and tag them? Something like a “backlog” of issues that fits well in the project, and even better, we can group them in two groups to expose our short-term and long-term project vision at the same time.
For that, we will use GitLab labels. They allow to query, edit and subscribe to the tasks assigned to them and display in a convenient UI. For that purpose I created two labels in the GNOME group, “Deliverable” and “Stretch”:
When a new issue is created, read it and if it’s something really wanted, doable and scoped tag it and move on. The rule of thumb is that you only tag issues that either someone works on them or you will eventually need to. Later on you can select the label to query them and do “sprints” of development, which it’s quite useful to focus for some days on code rather than project management or bug triaging, and also you can point to that label to other contributors to know what they can work on.
Everything here is automatically handled, when tasks are completed or closed they will disappear from the list of open issues, and we can sort them by closed date or other values that allows other teams and people to check the status. We no longer have to track tasks manually or put some strange wiki attributes and we can query all plans across GNOME.
Note that we are not pinning plans to a specific release. Also note that these are a moving target, that means that if there are 2 releases that the project was not maintained, they “do not count”. Let’s not kid ourselves, we are a contributor driven project and with our past roadmaps we have seen specific dates being more a failure than an achievement.
With this proposal, we allow for a more flexible project planning where time is not as much a constrain but rather we just tell what the project vision for the future is and what our priorities are. Designers, contributors, engagement team, users and downstreams now can provide early design advice, contributions, PR exposure and feedback & testing respectively.
Now we can query these, both for individual projects or across projects at GNOME:
We have achieved quite a few goals so far with this proposal, but we are missing to help a few people and teams, including the release notes writer, video making creator and release team for each release, after all what gets consumed is what’s released.
Here is the only case that a specific date will be set, aka a “milestone”, that are also available for the GNOME group. A milestone is only added if it’s sure that the task/issue/feature/fix will happen for that release, most probably after it’s implemented and merged, or if it’s considered a true blocker. In doing so other people can rely on those items, and maintainers only commit to a specific date when they are sure the fix/task is gonna happen or has happened.
With this proposal poor souls *cough* Allan *cough* hunting maintainers down to get what major changes happened in the projects for release notes won’t be necessary anymore. And other poor souls *cough* Bastian *cough* trying to make the release video won’t be as frustrated. The release team can also track better the releases.
Now we can answer what is going to be included in the release 3.30. or which major tasks are going to be included in 3.30 (epic + 3.30).
We now can plan and track tasks per project, and that’s already quite good! However, one of the questions we are missing to answer is, how about GNOME itself? Are there goals (or epics) for GNOME as a whole?
We had have a wiki page called initiatives in the past for that, and that was exactly its purpose. However, it was missing some bits to actually make it successful…
Apart of the missing automation of tasks and tracking, the way initiatives were defined were quite loosely, and most of the times there weren’t people in charge of making sure they happen. So the processes were quite cumbersome and the exposure of the initiatives were quite low, resulting on not very successful stories around that.
With those problems in mind, this proposal moves our initiatives effort to GitLab as a similar work flow than “Epics for GNOME”, provide templates for people to create them and automate as much as possible their tracking and delivery. For that purpose:
The project GNOME Initiatives has been created. The wiki with instructions is shown, and there is a template for creating an initiative.
Where the template will provide sections to fill, so there’s not need to think about the format and they will guide to provide useful information for others.
A label per each initiative is also created , so we can track the tasks assigned to a single initiative across projects. And last, we provide the same work flow and requirements as epics, so other people and teams know what to expect and can help make it happen or check the status easily.
For example, the first initiative created is to integrate Flatpak + CI for development of all core apps and newcomer apps. Quite useful! Go check it out as an example, and also take peek of it (not yet finished):
Big thanks to Jordan Petridis and Ernestas Kulik for being part of making this proposal to happen, I own them a drink!
In case it was not clear, I’m writing and doing all this work so neither me in the future or you have to, the whole point is that you just need to click 2 buttons and write 10 sentences and be done with it, if that’s not the case then I will need to improve the proposal.
Also, take this as an starting point, not as an end. There are not many new ideas here, more like trying to make them convenient, easy and straightforward once together. However believe me that I spent several days reading planning documentation and other issue trackers to make sure this is the best approach for GNOME. I’m looking forward to hear feedback and ideas from all and incorporate them, specially for the different teams at GNOME. This is going to be successful only if most of us at the core projects use it, and I think it will be beneficial for all of us.
And lately, consider that planning is not only about a maintainer and its code. A project at GNOME is also designers, is also engagement, is also release team, is also downstreams, and is also any potential contributor/tester/designer/marketing person that is not involved yet because we don’t expose our projects enough.
Cheers!
Hello all,
We are looking into adding an action & info bar to Nautilus. The background about this proposal can be read on the task where we put the main goals, prior art, different proposals and mockups, etc.
We are not sure whether this is the appropriate solution and whether the implementation we propose is ideal. In order to be more confident, we would like to gather early feedback on the current proposal. Also, we are looking for ideas on how to improve the overall approach.
The current proposal is being worked in a branch and can be installed via Flatpak clicking here (Note: You might need to install it the the CLI by executing `flatpak install nautilus-dev.flatpak` due to a bug in Software).
The current proposal looks as follows:
One of the concerns we have is about how visual heavy is to show the action bar at all times, in addition to the not very light buttons style.
One thing that could alleviate the heaviness is to style the buttons differently, and for that would be nice if someone that knows CSS plays a bit with it. To test your ideas, simply install the Flatpaked Nautilus, configure and open the GtkInspector with <ctrl>+<shift>+D, go to the CSS tab, and put the style you want to try out. To give some guidance, you have an example to make the action bar buttons flat here.
Feel free to comment here, reach me on IRC at #nautilus on irc.gnome.org as csoriano, or send an email to nautilus-list@gnome.org.
I will write an update in this blog with the outcome when we achieve some more advanced proposal with the feedback we have received.
I’m looking forward to hear your ideas and thoughts!
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? 🎉
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 ✌️.
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.
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:
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:
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.
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.
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.
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.
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!
csorianognome.wordpress.com 