Post 4.16 fatigue and what’s next
After we successfully released Xfce 4.16 as an early Christmas gift to all users last year I personally fell into the typical “post release fatigue” (PRF). On the one hand I was exhausted, on the other hand that’s how far our plans had taken us so there were no clear next steps we had settled on (apart from taking a break and recharging :)).
So what’s been going on since then…
Xfce 4.16 maintenance
First of all, we’ve done quite a few maintenance release of 4.16 to ensure it’s stability. We already provided lots of bugfix releases of 4.14 – some even very recently (Desktop, Appfinder) – but it looks like 4.16 may end up being (at least: among) the best maintained Xfce release so far.
Thunar is probably the active component with a 6th patch release being available already. Here goes an overview of all patch releases since 4.16.0 in December 2020:
- Thunar: 4.16.1, 4.16.2, 4.16.3, 4.16.4, 4.16.5, 4.16.6
- Panel: 4.16.1, 4.16.2
- Xfwm4: 4.16.1
- Garcon: 4.16.1
- Appfinder: 4.16.1
Developer documentation
In order to improve documentation for developers and make it more readily available we have started developer.xfce.org. For now this site hosts the API documentation of most relevant core components. This documentation is automatically kept up-to-date as part of our GitLab CI for the xfce/xfce-build Docker container and re-deployed on every week based on the latest 4.16 release tags.
Furthermore, we improved the shell-based helper scripts for developers, e.g. xfce-build (to locally run distcheck in the same Docker container used in our CI) with subcommands.
Task manager
I have fixed some bugs and done maintenance releases of the 1.4 series and started the 1.5 development series, which features a port of Task manager to Xfconf and Client-side decorations.
New icon naming scheme
As we changed the icon names for all Xfce components during the 4.16 cycle, I also migrated some plugins to the new naming scheme.
To briefly explain the rationale behind our change in 4.16: the previous names were highly inconsistent, overlapped with icons also used/shipped by other packages in distributions (so shipping our own icons with those “old” / “used” names would lead to unsolvable packaging conflicts). Especially the “standard” names like “preferences-desktop-*” would have been impossible to update and ship for us. In order to provide a consistent look and also to make it easier for icon theme maintainers to set up icons for Xfce we decided to follow the rDNS naming scheme for desktop files. The same naming scheme is already followed by Gnome, so it is fairly widespread in Gtk-based environments. Finally: previously no icon theme maintainer could even provide dedicated icons because the names overlapped and would also appear in other contexts or Desktop Environments.
Being an icon theme maintainer myself, I understood that this would lead to work for others. Sean even created a script to make it easier for everyone to update existing themes.
Plugin updates
I have taken a look at the three more prominent “monitoring plugins” of Xfce, namely CPU-graph, Systemload and Netload. I have created new icons for all three of them in a style consistent to the icons introduced in Xfce 4.16 and also ported Systemload to Xfconf.
I have also updated the Weather plugin quite a bit, adding a new icon, porting to Xfconf and improving the UX of the settings and forecast summary windows.
Finally some of the plugins mentioned above now implement the xfce_dialog_show_help API, which creates a “Help” button linking to the plugin’s documentation. This has been made possible by Kev, who ported the plugin documentation pages to docs.xfce.org and harmonized them, where possible. He also helped with adding more of these “Help” buttons and we’ll probably continue updating our plugins in parallel to the 4.18 cycle to make it easier for users to find the corresponding online documentation.
What’s next
The next step for me will likely be to focus on kickstarting the 4.18 cycle, which is still in its planning phase.
Xfce Panel Profiles 1.0.13 Released
Xfce Panel Profiles 1.0.13 has been released! The new release introduces new macOS and Windows layouts and improves on existing ones.
The post Xfce Panel Profiles 1.0.13 Released appeared first on Sean Davis.
Xfce 4.16pre2 released!
We are pleased to announce the second pre-release of Xfce 4.16 (a.k.a. xfce4.16pre2), moving us closer to the final release. As you all may have noticed, we are again a bit behind the schedule, but nothing like the 4+ years it took from 4.12 to 4.14, so please hold your excitement a tad longer while we are polishing the rough edges. For now, help yourself with the latest batch of changes:
Notable Changes
General
- More new app icons with rDNS naming scheme
- Bugfixes and minor improvements in all components
- Translation updates
Settings
- Disable UPower support by default
- Improve UX of settings dialogs (inline toolbar labels etc)
- Default Applications: Add ‘Open with…’ button to settings dialog
Libxfce4ui
- Revamped About Xfce tab
- Improve UI for setting shortcuts
- New API to launch “daemonized” processes
Panel
- Icon and appearance improvements
Power Manager
- More accurate status icons (Fixes #95) - 10 percent steps instead of “low, good, full”
- Respect the notification daemon’s timeouts (Fixes #57)
Session
- Tweak settings dialog (making columns sortable etc)
- Add xfsm-lock icon
Thunar
- Add support for transparency in gtk themes
Tumbler
- New thumbnailer plugin for epub files
Where can you get it?
Similary to pre1, you can either manually compile the tarballs or use xfce-test (ubuntu_20.04-xfce-4.16pre2 tag should be available at any moment) to enjoy a safe preview of Xfce 4.16. See the previous post for more options.
What’s next?
Finally, we will decide based on the feedback we get on pre2 whether to do a third pre-release or to go straight for the Xfce 4.16 stable release towards the end of the year. If no showstoppers are found we will try to release 4.16 still in 2020.
Xfce 4.16pre1 released!
As scheduled we have just released Xfce 4.16pre1 on August 27th (sorry for the long time to write a post about it) - the first development release leading up to Xfce 4.16. And it comes with a boatload of new features and improvements, so prepare yourselves.
Notable Changes
General
- Dropping lots of code (Gtk2 support), improving maintainability
-
Adding new icons to all core components to extend Xfce’s visual identity (also: follow freedesktop.org rDNS icon naming standard)
-
A revamped and improved “About Xfce” dialog that also holds general system details
-
Switch to client-side decorations for settings dialogs
- Lots of bugfixes everywhere
Settings
-
New “Default Applications” dialog: merge between “Mime Settings” and “Preferred Applications”
-
Display: Support for fractional scaling (with XRandR), better fallback in case of mis-configuration
-
Settings Manager: Improved search/filter
Panel
-
New Plugin: “Status Tray” - a merger between the systray and the statusnotifier plugin, will make life for users much easier and less confusing, now supports the panel’s global “icon size” setting
-
Autohide animation: Makes “autohide” more easily understandable (in the sense of: where did my panel just go?)
- Launchers now show desktop file actions on right-click (e.g. “Open a New Private Window” for Firefox)
-
The Window list now supports “launching a new instance” of an application in the right-click menu
- The Workspace switcher can optionally show numbering for workspaces
- Dark mode for the panel (precondition: your theme has to support dark mode)
Thunar
-
Copying and moving can be paused
- Support for queued file transfer (configurable)
- Initial support to remember view settings per directory
- New versioning scheme
Volman
- Removed PDA Tab
- New versioning scheme
Xfwm4
- Show alt-tab dialog only on the primary monitor (if one is set)
Power Manager
- Cleaner settings dialog (battery and “on power” settings)
- Optional visual indicator in the panel when “Presentation mode” is enabled
- Automatically dismiss low-power notifications upon connecting of a charger
Session
- Improved gpg-agent support
- Smaller visual cleanups
Appfinder
- Allow sorting apps by frecency (frequency and recency)
Thumbnailing Service
- Support for excluding paths (in the tumbler.rc settings file)
Xfconf Settings Service
- Enable gsettings backend by default
- Bash auto-completion for xfconf-query
- Drop Perl bindings
Where can you get it?
Besides manually compiling tarballs, it’s also possible to use xfce-test (ubuntu_20.04-xfce-4.16pre1 tag) to easily preview Xfce 4.16 without the risk of breaking your system.
Please go ahead try this release if possible, we would be more happy to hear your impressions as well as get bug reports before the final release.
What’s next?
We’re expecting to release Xfce 4.16pre2 at the end of this month and if necessary pre3 will be released in October. If everything goes as planned Xfce 4.16 should be released by November!
Xfce infrastructure in 2020
Oh boy, 3 years without any blogpost ! So much things happened in the Xfce world!
First, we finally released Xfce 4.14 in August 2019, more than 4 years of effort, a migration to gtk3, and so much new things, but you already know that, and you surely already run it.
We are now working on Xfce 4.16 , with the hope to release it this year (yes, in 2020) !
You can read more development news on our blog.
Some buzzwords: new icons, CSD, drop of gtk2 support, UI revamp, and tons of other stuff.
I want to talk a bit about the infrastructure.
Last year, we had a Gandi sponsorship for our servers. I started an Ansible repository with all our services (no more -undocumented- local modifications!), and we migrated a big part of our infra to the new servers (docs, www, wiki etc).
Then came the time to think about our development environment. We used the cgit/gitolite/bugzilla triptych, which worked fine for us for more than a decade, but make difficulty to have new contributor (our workflow was…hm, suboptimal).
We tested differents solutions (mainly Gitea and GitLab), and we opted for the famous Gitlab, already used by multiples open source projects. In the core team we were several to use it at work, so we were in a familiar environment.
For months, a gitlab was running on one of our Gandi instance, to do tests and prepare the transition.
But it was so much work that we never started the real migration. Then came the Covid-19 lockdown. No friends, no bars, lot of free time, so why not spent it on Xfce ?
With Simon (ochosi) and Andre (andreldm), we started to use our own gitlab by opening issues, creating todo, doing merge requests etc related to the migration.
The 1st of May, we finally did the migration to GitLab ! Woot !
Jason (j4yav), working for Gitlab inc, joined us and proposed to help us for the Gitlab CI/CD setup. At the same time, we got a new (sponsored !) VM from FossHost ! Perfect timing, we can now run a dedicated gitlab-runner instance, and we started to use gitlab-ci !
As of July 2020, almost all Xfce components (core, apps, panel plugins) run make distcheck on every merge requests and push to master, thanks to our xfce-build docker container.
Now that we have a beautiful GitLab, merge requests and CI, the only missing part was… the migration from Bugzilla !
I forked and modified bztogl, a tool developped and used by Gnome and Freedesktop folks when they migrated away from bugzilla to gitlab in 2018/2019.
Initially, we wanted to migrate all bugzilla issues to gitlab (opened and closed ones). But we had more than 15000 issues ! We decided to only migrate opened issues. We took the opportunity to do a biiig cleanup of old bugs by closing more than 500 of them.
A important condition of the bugzilla migration was to not lose our 15 years of history.
AndreLDM did a huge work by creating bzstatic, a tool to snapshot a bugzilla instance and make it a simple static html version : https://bugzilla.xfce.org.
He open sourced it at https://gitlab.xfce.org/andreldm/bzstatic !
As a result, we now have a modern developments workflow, fully integrated with gitlab. We enabled github and gitlab.com auth on our instance (some people requested it), and since 3 months, we’ve seen a surge of new contributors, issues and merge request ! Really a good news for the Xfce project ! We also had a sponsorship from Scaleway lately, that we need to set up !
So much things left to do, like update all our documentations for the new workflow, work on Xfce 4.16, get rid of our old release manager and use gitlab-ci to generate artifacts, simplify our translation workflow and tons of other things !
Enjoy !
Bountysource update
I quickly wanted to share an update to my previous post our leaving Bountysource behind (at least as platform for individual bug bounties).
Bountysource support has informed us that “All bounties on Xfce issues have been refunded and backers notified.”
If you are a backer of one of our issues registered on Bountysource and haven’t been refunded or at least approached please reach out to Bountysource support! (support@bountysource.com)
Meanwhile others (e.g. the elementary project) have also decided to move on for the same reasons…
Thunar, GtkAction and a big mess
Overview
My journey into the GtkAction abysses of Thunar began in the mid of 2019. Be warned, it is no story of success. It is rather a story about finding a way through a maze while walking into almost every dead end.
Actually I just wanted to fix #198 (Merge all file-context-menus into one). But somehow things got weird. More than half a year later and after numerous interactive rebases I finally merged my branch into master \o/
Motivation
The old Thunar used to create the same menu items in different places using different code. In the past that led to inconsistencies. E.g. the location bar only provided a very minimal context menu, no custom actions at all.
From time to time I found myself right-clicking on a location-button, just to find out that there still is no custom action. At some point of maximal annoyance I decided to fix that problem … not sure if I would have done so when I knew how long that road would be.
Looking at thunar-location-buttons.c revealed a lot of duplicated code. thunar-standard-view and thunar-window both used the deprecated GtkActionEntry to define menu item labels and related actions. The location buttons just mirrored parts of that code. On top some other actions were defined in thunar-launcher or had their own classes, inheriting GtkAction.
So yay, lets just copy+paste the missing stuff to the location buttons? Nah, that would be too easy. As a developer who values DRY, it would hurt my belief in clean code to produce more mess.
Let’s Start Hacking
I started to do some coding .. first I created a new widget thunar-menu which internally is a gtk-menu, and moved menu-item creation and the related actions for copy/cut/paste/delete/move_to_trash there to have them at some central place, so they can be reused by different menus. I as well moved the actions from thunar-launcher to thunar-menu (I guess the original intention of the launcher was, to actually launch things, not to manage menu-items) and replaced separate action classes in favour of methods inside thunar-menu.
Meanwhile the location-button-menu and the context-menu, which I used for testing, were populated with some items again.
The old code made massive use of the deprecated GtkAction and GtkActionEntry classes together with GtkUiManager. I did not want to add more G_GNUC_BEGIN_IGNORE_DEPRECATIONS to silence warnings. So I decided to replace the deprecated calls.
Looking into the gtk3 documentation revealed that there now is GAction and GActionEntry which provides some service around accelerator activation, and there is GtkMenu/GMenu for which at that time I had no clear idea why there are two of them.
The documentation of GAction told me that it should not be used for anything related to labels, icons or creation of visual widgets, damn. So at that time I did not see an advantage in using this class. I decided to rather go for GtkMenu together with some custom replacement for GtkActionEntry: XfceGtkActionEntry.
In retrospective ignoring GAction might not have been my smartest move. Meanwhile I understood how GAction can be used with GtkMenu, and I will most likely go for it at some later point.
Regarding GtkUiManager: The definition of menu-items of Thunar was scattered across 7 different *-ui.xml files, making it hard to figure out what belongs together. Because of that I decided to just get rid of the deprecated GtkUiManager and create menu-items in the code instead of predefining their order in xml. IMO the usage of xml files might be nice for static GUI’s, though for dynamic menu-creation it just introduces unnecessary complexity.
So I started to build XfceGtkActionEntry and some support methods.XfceGtkActionEntry is a structure which holds labels, tooltips, icons, types, the accelerator paths and callbacks to the related actions. Like GtkActionEntry it is just a struct and can be filled in a static way.
Next problem: The menus in Thunar so far did not get destroyed, but were updated whenever the selected items got changed, and got shown when needed. That sounded wrong to me. Why should I want to update menu-items, which can be expensive, while no menu is visible at all ? There were bugs about menu flickering and slowness while rubber banding/mass select which seem to be related. Since I anyhow needed to touch that part, I decided to build menus only when they need to be shown.
Things went well, I came to the point where I needed some items from thunar-window, like the zoom-section and the view-specific settings. As well most file-menu items in the thunar-window menu did not work any more since I moved management of them from thunar-launcher to thunar-menu. So next step clearly was: Introduce XfceGtkActionEntry to thunar-window … and than shit hit the fan.
So far the thunar-window menu was always present and took care for any accelerator actions. Since my concept was “create menu on request”, there was no menu instance which could take care for accelerators any more, leading to dysfunctional accelerator keys, rendering my whole concept as faulty .. aargh.
Start all over again
After some time of grieve and doubts I fixed the problem by moving most of the code from thunar-menu back to thunar-launcher, which lifetime is coupled to thunar-window.
From now on thunar-menu was more or less just an convenience wrapper for thunar-launcher … still useful, but sadly it lost its glory. thunar-launcher now builds volatile menu items on request and permanently listens to the related accelerators. Finally accelerators started to work fine, and I was able to continue to fight with the window menu.
I had much more trouble with that menu, too much to tell it here .. however somehow I managed to get it functional, so that it mostly worked like before.
An unpleasant discovery
Later on, while reporting a bug against gtk I learned that the class gtk_accel_map, which I use as a central part will be deprecated soon … aargh again. The gtk devs so far just missed to set a deprecation macro. So it seems like I will need to touch the accelerator part again. This time I plan to make use of the GActionMap interface .. going to be a story for another day.
Testing and open issues
For first testing and code-review I luckily got support of some early adopters. They found many more defects and regressions which kept me busy a long while. Fortunately nothing concept-breaking was found.
While writing this there are still some regressions I introduced, waiting to get fixed by me before a stable release:
- Regression: Missing accelerators for bookmark items
- GObject-WARNING on closing thunar in some conditions
And there are related tasks on my agenda, for which I just did not find the time so far:
- rename
thunar-launcherto e.g.thunar-action-manager - use
thunar-menuinbookmark view - use
thunar-menuinTree view - many minor things
Conclusion
Finally I ended up with 25 commits and +4717 / -7149 line changes. The occurrence of G_GNUC_BEGIN_IGNORE_DEPRECATIONS got reduced from 250 to 35. The remaining 35 occurrences will further drop when using GtkMenu for bookmark-view/tree-view. That should simplify the move to gtk4 in the future. The location-button context menu shows custom-actions now, and as well some other bugs got fixed with the changes.
So overall, the result does not look too bad I guess.
Well, this blogpost grew by far too long. I hope you nevertheless enjoyed the journey into the Thunar internals!
… enough storytelling for now, I really need to take care of these remaining regressions! :)
Thanks to Reuben, AndreLDM, DarkTrick and others for early testing and bug reporting! Special thanks to AndreLDM, motivating me to write this blogpost at all :D.
Thunar, GtkAction and a big mess
Thunar, GtkAction and a big mess
Overview
My journey into the GtkAction abysses of Thunar began in the mid of 2019. Be warned, it is no story of success. It is rather a story about finding a way through a maze while walking into almost every dead end.
Actually I just wanted to fix #198 (Merge all file-context-menus into one). But somehow things got weird. More than half a year later and after numerous interactive rebases I finally merged my branch into master \o/
Motivation
The old Thunar used to create the same menu items in different places using different code. In the past that led to inconsistencies. E.g. the location bar only provided a very minimal context menu, no custom actions at all.
From time to time I found myself right-clicking on a `location-button`, just to find out that there still is no `custom action`. At some point of maximal annoyance I decided to fix that problem ... not sure if I would have done so when I knew how long that road would be.
Looking at thunar-location-buttons.c revealed a lot of duplicated code. thunar-standard-view and thunar-window both used the deprecated GtkActionEntry to define `menu item labels` and related actions. The `location buttons` just mirrored parts of that code. On top some other actions were defined in thunar-launcher or had their own classes, inheriting `GtkAction`.
So yay, lets just copy+paste the missing stuff to the location buttons? Nah, that would be too easy. As a developer who values DRY, it would hurt my belief in clean code to produce more mess.
Let's Start Hacking
I started to do some coding .. first I created a new widget thunar-menu which internally is a gtk-menu, and moved menu-item creation and the related actions for copy/cut/paste/delete/move_to_trash there to have them at some central place, so they can be reused by different menus. I as well moved the actions from `thunar-launcher` to `thunar-menu` (I guess the original intention of the launcher was, to actually launch things, not to manage menu-items) and replaced separate action classes in favour of methods inside `thunar-menu`.
Meanwhile the location-button-menu and the context-menu, which I used for testing, were populated with some items again.
The old code made massive use of the deprecated `GtkAction` and `GtkActionEntry` classes together with `GtkUiManager`. I did not want to add more `G_GNUC_BEGIN_IGNORE_DEPRECATIONS` to silence warnings. So I decided to replace the deprecated calls.
Looking into the gtk3 documentation revealed that there now is GAction and GActionEntry which provides some service around accelerator activation, and there is GtkMenu/GMenu for which at that time I had no clear idea why there are two of them.
The documentation of GAction told me that it should not be used for anything related to labels, icons or creation of visual widgets, damn. So at that time I did not see an advantage in using this class. I decided to rather go for `GtkMenu` together with some custom replacement for `GtkActionEntry`: XfceGtkActionEntry.
In retrospective ignoring `GAction` might not have been my smartest move. Meanwhile I understood how `GAction` can be used with `GtkMenu`, and I will most likely go for it at some later point.
Regarding GtkUiManager: The definition of menu-items of Thunar was scattered across 7 different *-ui.xml files, making it hard to figure out what belongs together. Because of that I decided to just get rid of the deprecated `GtkUiManager` and create menu-items in the code instead of predefining their order in xml. IMO the usage of xml files might be nice for static GUI's, though for dynamic menu-creation it just introduces unnecessary complexity.
So I started to build `XfceGtkActionEntry` and some support methods.`XfceGtkActionEntry` is a structure which holds labels, tooltips, icons, types, the accelerator paths and callbacks to the related actions. Like `GtkActionEntry` it is just a struct and can be filled in a static way.
Next problem: The menus in Thunar so far did not get destroyed, but were updated whenever the selected items got changed, and got shown when needed. That sounded wrong to me. Why should I want to update menu-items, which can be expensive, while no menu is visible at all ? There were bugs about menu flickering and slowness while rubber banding/mass select which seem to be related. Since I anyhow needed to touch that part, I decided to build menus only when they need to be shown.
Things went well, I came to the point where I needed some items from `thunar-window`, like the zoom-section and the view-specific settings. As well most file-menu items in the `thunar-window` menu did not work any more since I moved management of them from `thunar-launcher` to` thunar-menu`. So next step clearly was: Introduce `XfceGtkActionEntry` to `thunar-window` ... and than shit hit the fan.
So far the `thunar-window` menu was always present and took care for any accelerator actions. Since my concept was "create menu on request", there was no menu instance which could take care for accelerators any more, leading to dysfunctional accelerator keys, rendering my whole concept as faulty .. aargh.
Start all over again
After some time of grieve and doubts I fixed the problem by moving most of the code from `thunar-menu` back to `thunar-launcher`, which lifetime is coupled to `thunar-window`.
From now on `thunar-menu` was more or less just an convenience wrapper for `thunar-launcher` ... still useful, but sadly it lost its glory. `thunar-launcher` now builds volatile menu items on request and permanently listens to the related accelerators. Finally accelerators started to work fine, and I was able to continue to fight with the window menu.
I had much more trouble with that menu, too much to tell it here .. however somehow I managed to get it functional, so that it mostly worked like before.
An unpleasant discovery
Later on, while reporting a bug against gtk I learned that the class gtk_accel_map, which I use as a central part will be deprecated soon ... aargh again. The gtk devs so far just missed to set a deprecation macro. So it seems like I will need to touch the accelerator part again. This time I plan to make use of the GActionMap interface .. going to be a story for another day.
Testing and open issues
For first testing and code-review I luckily got support of some early adopters. They found many more defects and regressions which kept me busy a long while. Fortunately nothing concept-breaking was found.
While writing this there are still some regressions I introduced, waiting to get fixed by me before a stable release:
- Regression: Missing accelerators for bookmark items
- GObject-WARNING on closing thunar in some conditions
And there are related tasks on my agenda, for which I just did not find the time so far:
- rename `thunar-launcher` to e.g. `thunar-action-manager`
- use `thunar-menu` in `bookmark view`
- use `thunar-menu` in `Tree view`
- many minor things
Conclusion
Finally I ended up with 25 commits and +4717 / -7149 line changes. The occurrence of `G_GNUC_BEGIN_IGNORE_DEPRECATIONS` got reduced from 250 to 35. The remaining 35 occurrences will further drop when using GtkMenu for bookmark-view/tree-view. That should simplify the move to gtk4 in the future. The `location-button` context menu shows custom-actions now, and as well some other bugs got fixed with the changes.
So overall, the result does not look too bad I guess.
Well, this blogpost grew by far too long. I hope you nevertheless enjoyed the journey into the Thunar internals!
... enough storytelling for now, I really need to take care of these remaining regressions! :)
Thanks to Reuben, AndreLDM, DarkTrick and others for early testing and bug reporting! Special thanks to AndreLDM, motivating me to write this blogpost at all :D.
Why Bountysource? Why?
TL;DR
- No more Xfce bugs on Bountysource.com (no support for GitLab)
- All remaining bug bounties returned to original backers
- Xfce Team account on Bountysource remains intact for now (including all donations so far)
Some background
When we kicked off Bountysource as one way to contribute to Xfce financially, this platform really seemed to be in a different place. It supported a multitude of bugtrackers (including our own, now archived, Bugzilla instance) and the web interface was frankly much more reliable.
When Bountysource decided to change its Terms of Service yesterday (note: the ToS change has been withdrawn since) this was a bit of a wake-up call for us. Let me briefly summarize: All uncollected bounties would after a fixed amount of time would have been withdrawn and the money retained by Bountysource. I can only presume that the business model of the platform is seriously struggling if such a drastic measure is imposed on the community when at the same time the fee of withdrawing/collecting bounties is at a not exactly unconsiderable 10%.
This all comes also after a so-called “inactivity fee” was introduced in 2018, which already felt strange and made me wonder what Bountysource does with all the money it holds for its users to justify such a fee. (Just putting the money in a regular bank account while holding on to it would earn you a little interest, as opposed to costing you – inflation ignored).
In any case, even if my reasoning above is not sound, we took the decision to disable bug bounties for Xfce starting now. This is the only reasonable step because GitLab is not supported, so we don’t have any way of updating our issues or confirming that they were closed (GitHub is the only supported platform these days).
The Bountysource Support team confirmed that all existing bug bounties will be returned to the original backers by them.
Please note that this change does not affect the Xfce Team account. We haven’t decided what our next step will be there but for the time being we will leave things as they are. So you can still donate to the Team and we can withdraw that money to use it for the project (footnote: we have not withdrawn anything so far).
GitLab CI is up and running
As announced less than two weeks ago, the next steps in our GitLab migration are following. While we originally planned that the migration from Bugzilla to GitLab issues would be the next step we received generous support from the brand new fosshost project: They provided us with the virtual infrastructure to be able to set up our first GitLab Runner.
A huge thank you to the fosshost for welcoming us aboard (and in record time)!
Standing on the shoulders of the xfce-test project by Florian and with support from A nice side-effect of having this container published on Dockerhub is that everyone can easily use it locally by running docker pull xfce/xfce-build.
If you’re curious what’s inside the container you can take a look at the Dockerfile. In short we use the latest Ubuntu 20.04 as a basis and then compile the Xfce core libraries based on the latest Git tag on the master branch.
The first project I set a pipeline up for is xfce4-settings. So from now on every commit and merge request will be built automatically and we as developers will receive immediate feedback. If you want to see what this looks like feel free to click here.
Next steps
Enabling the pipeline in more core repos will certainly be the next step. This should be as easy as adding this .gitlab-ci.yml file to the repository’s master branch and enabling the CI/CD feature of the project.
In parallel we have continued to work on the Bugzilla migration, but more on that later. Stay tuned!