atril (1.24.1-0ubuntu1) hirsute
- New upstream maintenance release.
Development release on the master branch.
One reason to do the next development release was, to get early testers for the changes on the shortcuts-view (unified context menu). Though the release as well ships various fixes, some smaller features and translation updates:
A bugfix and translation release on the 4.16 branch. Here the changes:
xfdashboard-0.9.1 "Gradients! Whoohoooo!" was released on 2021-03-19.
This is a development release.
From the moment an Ubuntu release (and flavors) reaches Final Freeze until the release is end-of-life (EOL), updates are released following the "stable release update" procedure, or SRU. This process is documented on the Ubuntu Wiki. However, it can be intimidating for new and long-time contributors and also confusing for users. I'd like to explain this process from a Xubuntu perspective.
We currently have two packages going through the SRU procedure for Xubuntu 20.04 and 20.10. After you've read this article, consider checking them out and helping with verification.
A common misconception about stable Ubuntu releases is that all bug fixes and new releases (small and large) will arrive via an update. There is not an automatic process for these updates to land in a stable release. Further, any fixes and new features have to be documented and tested according to the procedure above. As you might imagine, this can be a massive time sink.
Stable release updates specific to Xubuntu will generally be limited to high-impact bugs:
If an update meets these requirements, it is eligible to be updated with a Stable Release Update. Lower impact bugs will generally not be considered for SRU, but may be fixed in the -backports pocket or the Xubuntu QA Staging PPA.
If the bugs being fixed have already been reported on Launchpad, they will need to be updated with the SRU template. Other bugs and new features present in an upload should have new bug reports opened. Due to the time-based nature of landing a fix and following the SRU process, it can be a significant setback to have to start over, so more information is better than less. When in doubt, fill it out.
The standard SRU template typically includes the following sections: Impact, Test Plan, Where problems could occur (formerly Regression Potential), and Other Info. These sections help others who may not be completely familiar with the software or bug to be able to test it, and demonstrates that the upload and its regression potential has been sufficiently considered.
Once the bug reports are ready, the packages can be prepared and uploaded.
The first packaging-related step for a Stable Release Update is ensuring the fix is already released on the current development release. This may not always be applicable, but applies more often than not. Once the fix is verified in the development release, packages can be prepared for each affected stable release.
The packages are prepared with each bug fix linked in the Debian changelog. This will automatically update the affected bugs with status updates and tags and progress the bug status from In Progress to Fix Committed, and later to Fix Released. The packages are then uploaded to the -proposed pocket and Xubuntu SRU Staging PPA.
The Ubuntu SRU team is a small and busy one! Sometimes, it may take a few days for the team to review and accept the upload to the -proposed pocket. Once the package has been accepted, this starts the 7-day clock. Even after verification, a package upload must wait a minimum of 7 days before it is accepted into the -updates pocket.
SRU verification can be completed by any Launchpad user, and is recommended for getting a fix released to the -updates pocket sooner. Following the test cases documented on each bug report...
An update is considered verified if it has at least two positive and no negative testimonials. If you're affected by a bug that is going through SRU verification, please join in and provide your feedback on the fix.
Once an uploaded package has met the 7-day minimum wait and has been verified, it is eligible to be reviewed and released by the SRU team. Again, this can sometimes take more than 7 days, but if it seems to be running unusually long, add a comment (but please don't spam us) on the bug report to check in.
Finally, updates are phased, which means that a release package update may not show for a few days. Assuming there are no significant regressions that cause the update to be halted, the update should be available soon. Please be patient and respect that this process is designed to keep your computer running smoothly.
While not an exciting topic, I hope this helped to provide some insight into the inner workings of a stable Xubuntu release. Let me know if you have any questions or if I got something wrong. If you're working on another Ubuntu flavor or derivative, what's the post-development release process look like for your team?
Nearly two weeks have passed since I announced that I would be exploring development on elementary OS. I had more positive feedback than I expected, so thanks everybody for your awesome support! Since the announcement, I've been getting my feet wet with a few different elementary-related projects, and I think I'm starting to get the hang of things.
I've long been a fan of indicators, the modern replacement for Systray icons. Fewer apps are using Systray these days, and it has been deprecated across several desktops and toolkits. Replacing the Systray are AppIndicators (of the Ubuntu and Ayatana variety) and StatusNotifierItems. These have pretty wide support and are commonly used by messaging apps (Discord, Slack, Telegram) and cloud syncing apps (Dropbox, pCloud, SyncThing).
With a few development library updates, the existing version of the indicator did not support the upcoming Odin release. After a bit of hacking and experimentation, I got the package working fully. Check out the above pull request in case you need to get your indicator fix. In a less useful update, I also refreshed the packaging for elementary 5 "Hera".
I found this issue while browsing the Bitesize Issues found in the Desktop Development section of elementary's Get Involved page. Tabular numbers would prevent the file transfer dialog from jumping around, which seemed like a nice improvement. With the referenced code example, I was able to quickly identify the needed changes and get my hands dirty with a bit of Vala. After a code review and a small tweak, my pull request was merged!
After browsing the various projects and open issues, I became interested in hacking on the Wingpanel Sound Indicator. On the Xfce side, I've maintained the Xfce PulseAudio Plugin and Parole Media Player for quite some time and have some relevant experience to apply with MPRIS and DBus.
When I'm at my computer, I've always got Spotify playing in the background. Having the album artwork in the sound indicator is a nice touch, so I wanted to dig in and see if I could land a fix. Using DFeet, I was able to get the URL Spotify was sending, found it was returning a 404 response, and ultimately came across this post on the Spotify Community about the invalid URL.
I threw together a simple pull request to replace the invalid URL with a currently known working one (Vala makes this super simple) and sent it along. A couple of the elementary developers quickly responded with some valid feedback, including the simple fact that Spotify needs to fix their own app. If any Spotify developers are reading... please? :)
The Wingpanel Sound Indicator conveniently shows available media players, phones, and other devices that can be controlled via MPRIS. A device I didn't expect to see in the list was my Bluetooth headphones! Unsurprisingly, the media controls didn't have any effect on my headphones.
I did some more digging in DFeet, but the most useful property I could find was that this player uses the audio-card icon. I tracked down the icon-related code in bluez and used that as the basis for a new issue:
Here's hoping that one can get fixed upstream! If not, I'll continue exploring options for hiding this device in the Sound Indicator.
I'm having fun exploring the elementary code and issue trackers, and I think I'll be able to make some meaningful contributions to be project. I may spend a bit more time on the Wingpanel Sound Indicator before getting more out of my comfort zone with some larger projects. I've also got some updates coming for Xubuntu in the next couple of days, so watch my blog and Twitter for updates.
In case you'd like to join in, I recommend checking out the Get Involved page for ways to contribute. Additionally, elementary announced yesterday that they did not get accepted into the Google Summer of Code this year, but shared a list of potential projects to work on. There's some pretty substantial projects listed here, so if you're looking for something to do, this seems like a good opportunity.
Google Summer of Code was a little too full to accept us this year, but our ideas list is still a great place to find potential projects if you’d like to get involved!https://t.co/dmbHh79EoW pic.twitter.com/urrBaKWfLe
— elementary (@elementary) March 12, 2021