Apologies for slacking on the weekly posts since July. Starting from now, the weekly posts will now become monthly posts. This will give me more time to write about the developments that have happened each month, as there are times when I have a busy week that leaves me little time to spend on writing a weekly update. With only 12 updates per year, that will also make it easier for newcomers to follow current and past progress in Pop!_OS.Pop!_OS is a Linux distribution by System76, a Linux-based desktop hardware OEM. It is based on Ubuntu, with many enhancements specific to our vision of the desktop, and provides an optimal platform for our hardware, which is thoroughly tested throughout each release. These weekly posts highlight the developments that have been made each week in Pop!_OS.
Since the last update, the NVIDIA 430 and 435 drivers were released in Pop!_OS. A number of issues were discovered in the wild with the 430 driver that causes specific models of displays with specific EDID configurations to fail to display. Shortly after the 435 driver became stable, and testing found it to resolve this issue with monitor that we had which was affected by the issue, we pushed the 435 driver out as an update to 18.04 and 19.04.
In my last post, I mentioned that we could now use Rust 1.35.0 in Pop!_OS. Since then, Canonical has updated the Rust compiler across their releases to 1.36.0; which happened just in time for some dependencies which rely on that recently updated to require this as a minimum-supported version. It would seem that Canonical is following Rust releases more closely now, which puts it a much better position than we were in last year. Anyone targeting Ubuntu with applications written in Rust will have a much easier time getting their software on Launchpad, as a result.
In the last weekly post from July, the Firmware Manager was still in development. Shortly after, the Firmware Manager became the sole focus of development in Pop!_OS. Since then, it has been completed and released to every installation of Pop!_OS. Within Pop!_OS, the Firmware Manager is integrated into GNOME Settings within a new Firmware panel in the Devices category. The
firmware-managerpackage provides a standalone GTK application that can be used outside of GNOME, and in other Linux distributions which do not wish to embed the firmware manager application in GNOME Settings. Details on the firmware manager can be found here.
At this time, Firmware Manager only offers a GTK frontend. If you are a software developer experienced with Rust + Qt, or any other GUI toolkit, I welcome any contributions of alternative frontends in your preferred toolkit. The GTK frontend only contains logic specific to GTK, but is a great resource demonstrating how you should design alternative frontends. Rust is a requirement because the core library, which frontends are based upon, only exists as a Rust interface, and cannot easily be abstracted to a C interface due its use of various Rust concepts unavailable to C.
With the Firmware Manager complete, and the upcoming 19.10 release nearing release, the focus for Pop!_OS is now primarily on
pop-upgrade. At the time of writing this, the project is nearing completion, and should be ready in time for 19.04 -> 19.10 upgrades. The 18.04 LTS release shall also be supported, and is the active focus for the development and testing at this time.
The current phase of the project is to complete every functionality necessary to facilitate offline upgrades with systemd. This is the baseline that our upgrade mechanism falls back to when a recovery partition does not exist. It requires that we have desktop notifications, a GTK widget for GNOME Settings, and all functionality in the upgrade daemon and init script operating perfectly in every possible scenario. The development portion of this phase is now complete, and is currently being tested by our QA.
Once this is complete, the next phase will focus on testing and completing the functionality required for recovery upgrades. That will consist of updating the recovery partition with the daemon, setting the recovery partition as the default boot option for systemd-boot, and finally validating that both distinst and the installer are able to schroot into the base install to execute the init upgrade script and manage any of its failures. The development portion of this is also complete, so it will be ready for testing once QA approves of all changes to be made in the previous phrase.
The GTK widget for GNOME Settings, originally written in C, was rewritten in Rust, in the same fashion as was done for the Firmware Manager. The new GTK widget is now in a functioning state, with many more features than the original C attempt. Having a GTK frontend written in Rust as a widget library in workspace has enabled us to share the DBus client API with both the GTK and CLI frontends. This results in both frontends sharing the same code and behaviors for communicating with the upgrade daemon, therefore translating into less effort being duplicated.
Desktop notifications are now supported by the upgrade daemon. The notification, once clicked, opens the Info Overview in GNOME Settings, where options to upgrade the OS are presented. LTS releases will be able to dismiss the desktop notifications from within GNOME Settings, whereas non-LTS will continually be nagged until an upgrade is performed. If you would like to manually trigger the desktop notification, running
pop-upgrade release checkwithout a TTY, such as with
nohup, will execute the notification code.
We are hoping that these desktop notifications will increase the likelihood that our users will upgrade their OS to the next release before it becomes EOL'd. One of the issues with the current setup from Ubuntu is that our users aren't getting notified about release updates in a timely manner, or not at all. Our notifications are guaranteed to appear at login, and once every 24 hours, and will continue to nag the user until they upgrade, or the upgrade is dismissed.
In the event that a release is EOL'd, the upgrade daemon has logic to compensate for that, so that an upgrade succeeds. However, it will require that the upgrade daemon is installed, which won't occur if a user fails to update their system before 19.04 is EOL'd. Future releases of Pop!_OS will come with the upgrade daemon installed by default.
Conventional Commits & Git Workflow With Rebase
Rising in popularity in the Rust community, and open source software development at large, is the ability to automatically generate changelogs, and bump semantic versions, based entirely on git commits. To develop tooling which is capable of doing this, git commits must adhere to a standard convention which makes them machine-readable. Such conventions would require that each commit can be parsed using the same syntax rules, and that each commit has enough information to accurately describe the nature of the change that was made, and a description of that change.
The Conventional Commits specification provides exactly that. Every commit must define a type and optional scope, followed by a title describing the change. An optional body may be provided to explain the change in more detail, and to specify if the commit is a breaking change. This encourages commits to be maintained as lightweight patches that do one specific type of change per commit, which increases the discoverability of particular commits when searching through the history.
Over time, our projects will begin adorning a CHANGELOG.md file which describes each tagged release, and the changes and contributors who pitched in for each release. I've been experimenting with Jilu, a tool for generating changelogs for projects that adhere to the Conventional Commits guidelines. It uses a Tera template defined at the bottom of the changelog file to generate detailed changelogs based on the information parsed from commits and tags. There's currently a few rough edges with Jilu, so it will be some time before it's put to use in Pop!_OS.
This requires some changes to the way that git is used to manage commits in a project. Current and future developments are now oriented around a git workflow with git rebase, which prevents redundant commits, and merge commits with branching histories, from littering the git history. Essentially, when making changes to a pull request based on feedback received, prior commits related to that feedback will be amended with the changes required, instead of creating new redundant commits. Additionally, pull requests must be able to perform a clean merge into the master branch, without creating a merge commit, known as a fast-forward merged. Therefore, pull requests will be rebased as necessary to keep up with changes that have been merged into the master branch which conflict with a PR.
Since adopting this git workflow, I've revised the git histories of Pop Upgrade, Firmware Manager, and a few smaller projects to better adhere to the Convention Commit guidelines. I may revise other projects over time as time permits, and when it can be safe to do so, without causing conflicts with outstanding PRs. A great tool for revising commit histories in minimal time is git-revise.
Anyone submitting pull requests should adhere to these guidelines, especially if they're making substantial changes. Smaller pull requests will have their commit(s) squashed and rewritten by me if they aren't following the guidelines. In general, I will try to help contributors by rebasing their commits for them, until they learn how to do it themselves. I have a personal policy to not withhold PRs on the grounds of issues which are purely cosmetic, and easy to fix on my end. PRs which adhere to the guidelines will get merged quicker, however.
- Show all