Metered data hackfest

tl;dr: Please fill out this survey about metered data connections, regardless of whether you run GNOME or often use metered data connections.

We’re now into the second day of the metered data hackfest in London. Yesterday we looked at Endless’ existing metered data implementation, which is restricted to OS and application updates, and discussed how it could be reworked to fit in with the new control centre design, and which applications would benefit from scheduling their large downloads to avoid using metered data unnecessarily (and hence costing the user money).

The conclusion was that the first step is to draw up a design for the control centre integration, which determines when to allow downloads on metered connections, and which connections are actually metered. Then to upstream the integration of metered data with gnome-software, so that app and OS updates adhere to the policy. Integration with other applications which do large downloads (such as podcasts, file syncing, etc.) can then follow.

While looking at metered data, however, we realised we don’t have much information about what types of metered data connections people have. For example, do connections commonly limit people to a certain amount of downloads per month, or per day? Do they have a free period in the middle of the night? We’ve put together a survey for anyone to take (not just those who use GNOME, or who use a metered connection regularly) to try and gather more information. Please fill it out!

Today, the hackfest is winding down a bit, with people quietly working on issues related to parental controls or metered data, or on upstream development in general. Richard and Kalev are working on gnome-software issues. Georges and Florian are working on gnome-shell issues.

Parental controls hackfest

Various of us have been meeting in the Red Hat offices in London this week (thanks Red Hat!) to discuss parental controls and digital wellbeing. The first two days were devoted to this; today and tomorrow will be dedicated to discussing metered data (which is unrelated to parental controls, but the hackfests are colocated because many of the same people are involved in both).

Parental controls discussions went well. We’ve worked out a rough scope of what features we are interested in integrating into GNOME, and how parental controls relates to digital wellbeing. In this context, we’re considering parental controls to be allowing parents to limit what their children can do on a computer, in terms of running different applications or games, or spending certain amounts of time on the computer.

Digital wellbeing is many of the same concepts – limiting time usage of the computer or applications, or access to certain websites – but applied in a way to give yourself ‘speed bumps’ to help your productivity by avoiding distractions at work.

Allan produced some initial designs for the control centre UI for parental controls and digital wellbeing, and we discussed various minor issues around them, and how to deal with the problem of allowing people to schedule times when apps, or whole groups of apps, are to be blocked; without making the UI too complex. There’s some more work to do there.

On Tuesday evening, we joined some of the local GNOME developers in London for beers, celebrating the 3.32 GNOME release. ?

We’re now looking at metered data, which is the idea that large downloads should be limited and scheduled according to the user’s network tariff, which might limit what can be downloaded during a certain time period, or provide certain periods of the night when downloads are unmetered. More to come on that later.

For other write ups of what we’ve been doing, see Iain’s detailed write up of the first two days, or the raw hackfest notes.

Generate NEWS entries for GitLab projects

I’ve just published a small script to help generating NEWS file entries for projects which use GitLab:

https://gitlab.gnome.org/pwithnall/gitlab-changelog

Use it like this:

  1. Generate a GitLab api token at https://gitlab.gnome.org/profile/personal_access_tokens.
  2. Run gitlab-changelog.py GNOME/glib 2.58.2.. -H https://gitlab.gnome.org/ -t ${generated_token}.
  3. Copy the output (below the dashed line) into your NEWS file entry. There are some blanks (indicated by TODO) in the entry which you need to fill in yourself.

The next time you run the script, you don’t need to pass the -H or -t options, as the configuration is saved in ~/.config/gitlab-changelog.ini.

I’ve used it on the last few GLib releases, which have seen a lot of issues fixed and MRs merged, and it sped up writing the NEWS file.

I haven’t tested it on other projects, or other GitLab instances, but it should work with them. Merge requests with improvements are very welcome.

GUADEC 2018 thoughts

GUADEC this year was another good one; thank you to the organisers for putting on a great and welcoming conference, and to Endless for sending me.

Unfortunately I couldn’t make the first two days due to a prior commitment, but I arrived on the Sunday in time to give my talks. I’ve got a lot of catching up to do with the talks on Friday and Saturday — looking forward to seeing the recordings online!

The slides for my talk on the state of GLib are here and the notes are here (source for them is here). I think the talk went fairly well, although I imagine it was quite boring for most involved — I’m not sure how to make new APIs particularly interesting to listen to!

The slides for my talk on download management on metered connections (the ‘Mogwai’ project) are here and the notes are here (source for them is here). I think this talk also went fairly well, and I’m pleased by how many people turned up and asked insightful questions. As I said in the talk, my time to spend on this project is currently limited, but I am interested in mentoring new contributors on it. Get in touch if you’re interested.

During the birds of a feather days, I spent most of my time on GLib, clearing out old bugs. We had the GLib BoF during the GTK+ one on Monday. The notes are here. Emmanuele has already done a good writeup of the results of the BoF here; and Matthias has written up the GTK+ BoF itself here.

There were some good discussions over dinner during the BoF days about people’s niggles with GLib, which has set a few ideas in motion in my head which I will try and explore over the coming few months, once the 2.58 release is out of the way.

It was good to catch up with everyone, great to see Almería and sample its food and drink, and nice to finally meet some of my colleagues from Endless for the first time!

Going to GUADEC: talking about the state of GLib and metered data handling in downloads

I’ll be at GUADEC in Almería this year, giving two talks on Sunday:

  • GLib: What’s new and what’s next?, which will be a general overview of recent developments in the GNOME utility library, some future plans, and some stats about what happens to contribution rates when you move to GitLab and Meson.
  • Download management on metered connections, which will be an overview of the Mogwai project, which I’ve worked on in recent months at Endless. Mogwai is a download scheduler, which your code can use to determine the best time to do a big download to avoid incurring bandwidth charges from your internet provider (if you’re on a metered connection).

I won’t be arriving until Sunday morning, but will be around until Thursday (12th) morning, and will be in the GTK+/GLib BoF on Monday in room 2 to plot the next GLib release.

Shout out to my coworker Matthew Leeds’ talk, on P2P Distribution of Flatpaks and OSTrees, which comes towards the culmination of a lot of work by him (and others in Endless, and upstream OSTree and flatpak) to introduce peer to peer support in OSTree and flatpak, so you can distribute OSs and apps using USB sticks and the LAN.

Automatically shutting down a daemon on inactivity

tl;dr: Use gss_service_hold() and gss_service_release() from libgsystemservice.

Automatically shutting down daemons when not in use is in vogue, and a good way of saving resources quite easily (if the service’s startup/shutdown costs are low).

libgsystemservice can do this for you automatically, if your code is based on GssService, or if you want to port over to it (which should be fairly straightforward for simple services). It supports inactivity timeouts by default; just call gss_service_hold() when you start doing some activity, and gss_service_release() when you stop.

(Also, look, it’s neat that you can generate documentation and automatically publish it from your master branch using GitLab CI!)

libgsystemservice: a library for writing D-Bus system services

Having written a few D-Bus system services recently, it felt like I was cargo-culting the same bits of code in all of them. I’ve split some of that out into a new library, libgsystemservice, which I hope will grow to contain all the bits people need to write D-Bus system services and other system daemons.

At the moment, it includes a way to load configuration files from multiple directories (with /etc taking priority over /usr/share, for example); tracking of D-Bus peers which have interacted with your service, and their credentials; and an equivalent of GApplication for system services. (GApplication only works on the session bus, and has various features targetting user applications which aren’t appropriate for system services.)

We’re using this code within Endless at the moment; but the more users it has, the better. Feedback and contributions are very welcome on GNOME’s GitLab.

GTK+ hackfest and FOSDEM: outcomes

Last Thursday and Friday was the GTK+ hackfest in Brussels. Matthias and Timm have blogged about GTK+ discussions already. This post is about the GLib side of things.

Firstly, we’re moving to Meson, but with no regressions from autotools. The plan is to target functional compatibility with autotools for 2.58, to keep both build systems in parallel for a release or two, and then drop autotools as soon as we can be satisfied there are no regressions for any of our features or supported platforms. I’d like to encourage distributions and developers to start trying to build GLib with Meson, seeing what breaks, and filing bugs.

Secondly, we’re migrating to gitlab, slowly. The first step is to migrate from cgit to gitlab, which will allow us to set up continuous integration for GLib. This will be a big win. The second step will be to migrate Bugzilla to gitlab. That’s going to take a bit longer, since there are issues with getting the data out of Bugzilla efficiently. All open bugs will be transferred, just like with the other gitlab transitions so far.

The maintainership status of GLib was also discussed. We are short on people power, and would appreciate assistance. If your project or company relies on GLib, please consider helping out with patch review or writing patches. We have three part-time maintainers who can provide guidance and help. We’re particularly interested in finding people to help maintain the platform ports of GLib, like Windows, OS X or BSD, more officially. Find us in #gtk+ on irc.gnome.org.

We also discussed a number of other, smaller features and issues, which might get handled for 2.58 depending on time. If you would like to work on any of them, please do! We can provide guidance and patch review in Bugzilla.

Thanks to Matthias and Emmanuele for organising the hackfest, Allison for turning up and imparting sage GLib wisdom, and Purism for kindly sponsoring dinner on Friday night.

GTK+ hackfest and FOSDEM

Courtesy of my employer, Endless (we’re  hiring), I’m at the GTK+ hackfest in Brussels, which is acting as my warm up for FOSDEM 2018. I’m representing the assorted GLib maintainers, aiming to look at the roadmap for GLib 2.58, and what we need to do to finish off GLib 2.56. If you’ve got suggestions for new features or changes to GLib, get in touch or file a bug!