We just landed the largest refactor to Builder since it's inception. Somewhere around 100,000 lines of code where touched which is substantial for a single development cycle. I wrote a few tools to help us do that work, because that's really the only way to do such a large refactor.

Not only does the refactor make things easier for us to maintain but it will make things easier for contributors to write new plugins. In a future blog post I'll cover some of the new design that makes it possible.

Let's take a look at some of the changes in Builder for 3.32 as users will see them.

First we have the greeter. It looks virtually the same as before. However, it no longer shares it's windowing with the workspace that is opened. Taking this approach allowed us to simplify a great deal of Builder's code-base and allows for a new feature you'll see later.

The UI might change before 3.32, but that depends on our available time and some freezes.

Builder now gives some feedback about what files were removed when cleaning up old projects.

Builder gained support for more command-line options which can prove useful in simplifying your applications setup procedure. For example, you can run gnome-builder --clone https://gitlab.gnome.org/GNOME/gnome-builder.git to be taken directly to the clone dialog for a given URL.

The clone activity provides various messaging in case you need to debug some issues during the transfer. I may hide this behind a revealer by default, I haven't decided yet.

Creating a new project allows specifying an application-id, which is good form for desktop applications.

We also moved the "Continue" button out of the header bar and placed it alongside content since a number of users had difficulty there.

The "omni-bar" (center of header bar) has gained support for moving through notifications when multiple are present. It can also display buttons and operational progress for rich notifications.

Completion hasn't changed much since last cycle. Still there, still works.

Notifications that support progress can also be viewed from our progress popover similar to Nautilus and Epiphany. Getting that circle-pause-button aligned correctly was far more troublesome than you'd imagine.

The command-bar has been extracted from the bottom of the screen into a more prominent position. I do expect some iteration on design over the next cycle. I've also considered merging it into the global search, but I'm still undecided.

Also on display is the new project-less mode. If you open Builder for a specific file via Nautilus or gnome-builder foo.c you'll get this mode. It doesn't have access to the foundry, however. (The foundry contains build management and other project-based features).

The refactoring not only allowed for project-less mode but also basic multi-monitor support. You can now open a new workspace window and place it on another monitor. This can be helpful for headers, documentation, or other references.

The project tree has support for unit tests and build targets in addition to files.

Build Preferences has been rebuilt to allow plugins to extend the view. That means we'll be able to add features like toggle buttons for meson_options.txt or toggling various clang/gcc sanitizers from the Meson plugin.

The debugger has gone through a number of improvements for resilience with modern gdb.

When Builder is full-screen, the header bar slides in more reliably now thanks to a fix I merged in gtk-3-24.

As previewed earlier in the cycle, we have rudimentary glade integration.

Also displayed here, you can select a Build Target from the project tree and run it using a registered IdeRunHandler.

Files with diagnostics registered can have that information displayed in the project tree.

In a future post, we'll cover some of what went into the refactoring. I'd like to discuss how the source tree is organized into a series of static libraries and how internal plugins are used to bridge subsystems to avoid layering violations. We also have a number of simplified interfaces for plugin authors and are beginning to have a story around ABI promises to allow for external plugins.

If you just can't wait, you can play around with it now (and report bugs).

flatpak install https://gitlab.gnome.org/GNOME/gnome-apps-nightly/raw/master/gnome-builder.flatpakref

Until next time, Happy Hacking!

17 Jan 2019 3:06am GMT

This is just to help remember:

If you have used G_DECLARE_* macros in a C class header in order to modernize your old C code to resent GLib class definition methods; you are using GObject Introspection to parse it and generate GIR files; and you get this error:

"Fatal: Gda: Namespace conflict for 'your_type_get_type'"

Then remove your "*_get_type()" method definition from your header file.

Above have been the result to modernize GDA to resent practices and could be helpful for any one else.

15 Jan 2019 7:22pm GMT

I usually speak and write in English, but for this article, I am writing it in Spanish.

A few weeks ago, I read a blog article by my intern Clarissa in Outreachy. In her article, Clarissa wrote about her challenges in the program. One challenge for her was writing in English. Her native language is Portuguese.

Clarissa's writing is so good that I often forget that English is not her native language. So I wanted to share that experience by writing a blog article of my own in another language. I can speak some Spanish; I learned it in high school and lived for part of a summer in Mexico (about a month, part of a student-abroad language-immersion program for advanced students). But I don't write in Spanish very well.

Writing in Spanish is very difficult for me. I know many of the words, but some I need to translate via Google Translate. I'm sure I'm writing seems stilted and awkward. That's because I'm writing in a language that I don't usually write in.

I support Clarissa in her internship. Writing in another language is really difficult. I can do it, but it takes about twice the time for me me to write what I want to because I'm not very strong in the Spanish language. From this, I can really appreciate the challenges that Clarissa goes through in writing for Outreachy.

14 Jan 2019 10:28pm GMT

Yo hablo y escribo inglés. Pero para este artículo, yo escribo en español.

Hace unas semanas, leí un artículo del blog de mi pasante Clarissa en Outreachy. En su artículo, Clarissa escribió sobre sus desafíos en el programa. Un desafío fue escribir en inglés. Su lengua natural es el portugués.

La escritura de Clarissa es buena porque a olvido que el inglés no es su lengua natural. Así que quería compartir la experiencia escribiendo un artículo de mi blog en otro lengua. Puedo hablar algo de español; lo aprendí en la escuela secundaria y durante viví un verano en México. Pero no escribo muy bien el español.

Escribir en español es muy difícil. Conozco muchas de las palabras, pero algunas tengo que traducirlas en Google Translate. Estoy seguro de que mi escritura parece incómoda. Eso es porque estoy escribiendo en una lengua que no suelo escribir.

Apoyo a Clarissa en su pasantía. Escribir en otro idioma es muy difícil. Puedo hacerlo, pero me lleva mucho tiempo escribir lo que quiero porque no domino el idioma español. Aprecio más los desafíos que Clarissa tiene por escrito para Outreachy.

14 Jan 2019 10:18pm GMT

Adwaita has been the default GTK+ theme for quite a while now (on all platforms). It has served us well, but Adwaita hasn't seen major updates in some time, and there is a desire to give it a refresh.

Updating Adwaita is a challenge, since most GTK applications are using the stable 3.x series, and some of them include Adwaita-compatible theming for their own custom widgets. Given the stable nature of this release series, we don't want to cause theme compatibility issues for applications. At the same time, 3.x is the main GTK version in use today, and we want to ensure that GTK applications don't feel stale or old fashioned.

A trial

A number of approaches to this problem have been considered and discussed. Out of these, a tentative plan has been put forward to trial a limited set of theme changes, with the possibility of including them in a future GTK 3 release.

Our hope is that, due to the limited nature of the theme changes, they shouldn't cause issues for applications. However, we don't want to put our faith in hope alone. Therefore, the next three weeks are being designated as a testing and consultation period, and if things go well, we hope to merge the theme into the GTK 3.24.4 release.

It should be emphasised that these changes are confined to Adwaita itself. GTK's CSS selectors and classes have not been changed since GTK 3.22, and the changes in Adwaita won't impact other GTK themes.

The Adwaita updated theme is being made available as a separate tarball in parallel with the GTK 3.24.3 release, and can be downloaded here. GTK application developers are invited to try 3.24.3 along with the new version of Adwaita, and report any issues that they encounter. The GTK team and Adwaita authors will also be conducting their own tests. Details of how to test the new theme in various ways are described here.

We are hoping to strike a balance between GTK's stability promises on the one hand, and the desire to provide up-to-date applications on the other. It is a delicate balance to get right and we are keen to engage with GTK users as part of this process!

Theme changes

The rest of this post summarises which changes are have been made to the theme. This will hopefully demonstrate the limited extent of these changes. It will also help developers know what to look for when testing.

Colors

Many of the Adwaita colors have been very slightly tweaked. The new colors are more vivid than the previous versions, and so give Adwaita more energy and vibrancy. The new colors also form part of a more extensive palette, which is being used for application icons. These colours can also be used in custom application styling.

The color changes are subtle, so any compatibility issues between the new and the old versions should not be serious. Blue is still blue (just a slightly different shade!) Red is still red. Visually, the dark and light versions of the theme remain largely the same.

Adwaita's dark variant, showing the slight color changes between old (left) and new (right).

Note that the red of the button has been toned down a bit in the dark theme.

Header bars and buttons

Most widgets have not been specifically changed in the updated version of Adwaita. However, two places where there are widget-specific changes are header bars and buttons. In both cases, an effort has been made to be lighter and more elegant.

Buttons have had their solid borders replaced with shadows. Their background is also flatter and their corners are more rounded. Their shape has also been changed very slightly.

Header bars have been updated to complement the button changes. This has primarily been done by darkening their background, in order to give buttons sufficient contrast. The contrast between header bars' focused and unfocused states has also been increased. This makes it easier for users to identify the focused window.

At first glance, these changes are some of the most significant, but they are achieved with some quite minor code changes.

The header bar in GNOME's Calendar app (old version on top, new version on the bottom):

Switches

Aside from header bars and buttons, the only other widget to be changed is switches. When GTK first introduced switches, they were a fairly new concept on the desktop. For this reason, they included explicit "ON" and "OFF" labels, in order to communicate how the switches operated. Since then, switch widgets have become ubiquitous, and users have become familiar with switches that don't contain labels.

The latest Adwaita changes bring the theme into line with other platforms and make switches more compact and modern in appearance, by removing the labels and introducing a more rounded shape.

Elsewhere, no change

Aside from the changes described above, very little has changed in Adwaita. The vast majority of widgets remain the same, albeit with very slightly altered colours. Generally, UI layouts shouldn't alter and users should feel comfortable with the changes.

Spot the difference (the old version of Adwaita is on the left and the new version is on the right):

Conclusion

Please try the new theme. We hope you like it!

And we appreciate your feedback-in particular if you are a GTK application developer. You can provide it on irc (in the #gtk+ channel on GimpNet) or via the gtk-devel-list mailing list, or by filing an issue in gitlab.

14 Jan 2019 7:22pm GMT

Here you can find the introduction, the update 1 and the update 2.

Notification if you replug your main keyboard

As of now we allow a single keyboard even if the protection is active because we don't want to lock out the users. But Saltarelli left a comment making me notice that an attacker would have been able to plug an hardware keylogger between the keyboard and the PC without the user noticing.

To prevent this now we display a notification if the main keyboard gets unplugged and plugged again.

Smart authorization with touchscreen

If your device can use the touchscreen and your physical keyboard breaks you should be able to use your device because you'll have a working on-screen keyboard. Because of this I added an exception to the auto authorization of keyboards if touchscreen is also available. Thanks to Marcus for this hint.

GNOME Shell protection status

Now GNOME-Shell shows an icon in the status bar only if the protection is really active. In order to reliably test it we check both the gsetting protection value and also if the USBGuard DBus is really up and running.

As shown in the screenshot below we are currently using a generic "external device" icon. Before the final release we should change it, hopefully with an external help :)

GNOME Control Center

GNOME Control Center before showed just an "on"/"off" label next to the "forbid new USB devices" entry. Now a more informative label has been added. In this way we can show directly the protection level in use.

On top of that, we also check for the USBGuard DBus availability. If it is not available we show the current protection level as "off" and we prevent the users to interact with the USB protection dialog.

Limit keyboards capabilities

As I said briefly in the last update, the goal here is to prevent new keyboards from using dangerous keys (e.g. ctrl, alt ecc…).

At the beginning I tried to experiment with scancodes. One possible approach was to append to the hwdb an always limit rule like this:

evdev:name:*:dmi:bvn*:bvr*:bd*:svn*:pn*    # Matches every keyboards
    KEYBOARD_KEY_700e0=blocked             # Block left ctrl
    [...]

Then when we wanted to grant full access to a single keyboard we appended a device specific rule (vendor, product, version ID and input-modalias of it) mapping back every previously blocked keys.

While at first this seemed a feasible option, after a few emails and a call with Peter Hutterer and Benjamin Tissoires we decided to discard it in favour of a device grabbing with EVIOCGRAB/libevdev_grab().

For example one problem with scancodes mapping using the hwdb was that the matches were not predictable if there were multiple of them applied to a single device (first the always block and then the permission granted).

EVIOCGRAB and Mutter

The route we are taking is to implement the key filtering directly in mutter (my early work on it). As soon as we have a new device we take the grab on it with EVIOCGRAB, in this way we will be the only one that can see the device key events. Then when a key gets pressed we check if it is a dangerous key. If it is we drop it.

With this approach for example we still can get notified when a dangerous key is pressed (as opposite to the scancodes approach). In this way we can display a notification saying that the device is limited, so nothing happened because a key has been blocked and not because the keyboard is broken.

How to handle this in the UI is still under discussion and evaluation. Maybe we can start with showing a list of connected keyboards in GNOME Control Center. Next to every entry in this list we could put a colored icon to show the current device status. That is could be either limited or full access. Then the users will be able to toggle this icon changing the specific device permission.

What to expect next and comments

In the next days I'll try to refine the "limit keyboards" functionality and I'll try to come up with a way to expose this feature to the end users. Also related to the smart authorization, we should also check for other input devices like keyboards on the legacy PS/2 port.

Feedback is welcome!

14 Jan 2019 3:22pm GMT

The Outreachy program is a three month internship to work in FOSS. There are two periods for the outreachy, the first one from December to March and the other one from May to August. It's similar to the Google Summer Of Code, but in this case the interns doesn't need to be students.

I proposed some ideas for interts to work on GNOME, with me as a mentor. I wrote three proposals this time:

• Extend Fractal media viewer with video support and explore video conference
• Create Gtranslator initial integration with Damned Lies
• Books : Improve the epub support in gnome-books

There was people interested in all of three projects, but for the Books app we don't have any real contribution so there was no real applicants.

I've two good proposals for Fractal and for Gtranslator, so I approve both and the Outreachy people approve these two interts. So we get two new devs working in GNOME for three months as interns.

This is something great, paid developers working in my proposals is a good thing, but this implies that I need to do the mentor work for these two interns during the three months period, so it's more work for me :/

But I think this is a really important work to do to bring more people to the free software, so I've less time for hacking, but I think it's good, because the fresh blood can do the hacking and if, after the Outreachy, one of the interns continues collaborating with GNOME, that will be more important for the GNOME project that some new features in one app.

GNOME Translation Editor

Teja is the intern working in gtranslator. She is working in the Damned Lies integration.

Damned Lies is a web application for GNOME translators. This app provides updated .po file for each GNOME module and language and translators can download and update that file using the web interface. That web is able to do the commit to the original repository with the upload version from translators.

The idea is to provide a simple integration with this platform in the GNOME Translation Editor app, using the web json API to be able to open .po files from the web directly without the need to download the file and then open it.

The current API of DL is really simple so we can't implement a real integration without adding more functionality to this API. So this project requires some work in the DL app too.

In the future we can improve the integration adding the posibility to upload the new .po after saving to DL so translators doesn't need to go to the web interface and can do all the translation flow using only the Translation Editor.

Fractal

Maira is the intern working in Fractal. They are working in the initial video preview widget.

Fractal is a instant messaging app that works over matrix.org. Currently we support different types of messages, like text, images, audio and files. But for video we're using the same widget as we're using for files, so you can download or open, but we've not a preview or inline player.

The main idea of this project is to provide a simple video player using gstreamer to play the video inside the Fractal app.

This is not an easy task, because we're using Rust in Fractal and we need to deal with bindings and language stuff, but I think it's doable.

During the internship, Maira is also working fixing some bugs in the audio player, becuase it uses gstreamer too, so during the code review, Maira detected some problems and they are fixing it.

13 Jan 2019 10:23am GMT

The internationalization of my career was a spotlight in 2008 starting in the U.S.A. with an internship at ORNL in February 2018 and then in U.K. with a Master in HPC (High- Performance Computing) on September 2018. Some online articles can be found chronologically with my active participation and efforts done during the year 2018.

1. Organizing an HPC event

Usually, July is the month in where many interns go to ORNL to have real-world experiences in their fields. Some of them are students from schools, colleges, and universities and I had enough time to interact with most of them and to realize that some of them need more preparation in topics related to HPC such as Linux commands, HPC concepts, Programming, and Deep Learning. This is the web configured to do it:

After the successful event, a note was published in the Sci Ed Programs Summer 2018 Newsletter, Issue 11. I was so happy to help in training students from many countries.

2. ORNL Photo Story Contest

It was announced a contest of photography about posting photographies related to the internship of students and my picture was published in the Sci Ed Programs Summer 2018 Newsletter. In this magazine, local events in Knoxville and useful ORNL tips were pointed.

Sci Ed Programs Summer 2018 Newsletter, Issue 13 announced the winner of the contest and surprisingly my group got the second place in a picture we took at Smoky Mountain.

https://wakelet.com/wake/0970235f-b3ed-40bf-9fb2-9bd3f2e4960d

3. ORNL 75 years

The official video was publicly released and 0:33 captured the work I did as a volunteer in the core day of the 75 years of the creation of the Oak Ridge National Laboratory in TN.

https://www.youtube.com/watch?v=OEOHk4wQeTkfg

4. OLCF

Five OLCF students of 26 were selected to share their experiences and accomplishments during the internship period. I am so happy with the recognition received for my work.

https://www.olcf.ornl.gov/2018/08/07/summer-interns-gain-hpc-skills-professional-development-at-the-olcf/

5. EPCC

I decided to prepare myself further in HPC(High-Performance Computing) and I applied to the school of Informatics in Edinburgh where they have a Master in High Performance Computing. I traveled to Scotland to learn from the world-class staff of EPCC that have more than 20 years of experience in teaching parallel programming worldwide.

https://www.epcc.ed.ac.uk/sites/default/files/EPCC%20News%2084.pdf

6. ORISE

On December it was published my profile after the internship done in ORNL where they highlighted the passion at work I demonstrated while interacted with leadership-class computing systems for open science in the CADES area with an OpenShift project.

https://orise.orau.gov/ornl/experiences/recent-graduates/inca.htmlFinally, my participation was printed to inspire other students to be involved in STEM:

11 Jan 2019 7:07pm GMT

The start of a new year often brings change. Our family has increased in size, which is very exciting. I'm also moving on from Endless and have a new job Managing Product at Lucid. I'm sad to be leaving my friends at Endless after a couple of delightful and very satisfying years but I'm also very pleased to be working with Jonty and Jono again. I still remain as emotionally invested in the GNOME and Flatpak communities as ever - I just won't be paid to contribute, which is no bad thing for an open source project.

11 Jan 2019 5:53pm GMT

Last month I was in Seville for the second Fractal Hackfest. It was a bit of a different experience for me than the other hackfests I have been too, as I'm a core member to the project now, and I also knew most of the other people already.

My main focus for this hackfest was to push forward the work on the Fractal backend. The backend should handle persistent storage and the preparation of data needed in the UI. Right now many things which should conceptually be in the backend are in the frontend, and can therefore cause UI freezes. Over the past months I have been working hard on refactoring the code so we can just drop in the backend without making many changes to the UI code. So the core of the refactors I did was to make sure that data flows in one direction and we don't keep different copies of the data around.

Backend

For storage we decided to use SQLite instead of LMDB because we have many relations between the data. The data will be structured into 3 tables: USERS, ROOMS, MESSAGES. This gives us a lot of space to expand and allows us to reference to other data with ease.

The backend will have use a glib based API to communicate with the frontend, and on the other hand it will have a Rust only interface to communicate with fractal-matrix-api.

Community

Lunch at a spanish Pizza place

We also had really awesome community bonding events, and some local newcomers joining the hackfest. Thanks to Daniel for organizing the event and also all locals who helped him.

11 Jan 2019 11:54am GMT

Since a few days ago, librsvg's library implementation is almost 100% Rust code. Paolo Borelli's and Carlos Martín Nieto's latest commits made it possible.

What does "almost 100% Rust code" mean here?

• The C code no longer has struct fields that refer to the library's real work. The only field in RsvgHandlePrivate is an opaque pointer to a Rust-side structure. All the rest of the library's data lives in Rust structs.

• The public API is implemented in C, but it is just stubs that immediately call into Rust functions. For example:

gboolean
rsvg_handle_render_cairo_sub (RsvgHandle * handle, cairo_t * cr, const char *id)
{
    g_return_val_if_fail (RSVG_IS_HANDLE (handle), FALSE);
    g_return_val_if_fail (cr != NULL, FALSE);

    return rsvg_handle_rust_render_cairo_sub (handle, cr, id);
}

• The GObject boilerplate and supporting code is still in C: rsvg_handle_class_init and set_property and friends.

• All the high-level tests are still done in C.

• The gdk-pixbuf loader for SVG files is done in C.

Someone posted a chart on Reddit about the rustification of librsvg, comparing lines of code in each language vs. time.

Rustifying the remaining C code

There is only a handful of very small functions from the public API still implemented in C, and I am converting them one by one to Rust. These are just helper functions built on top of other public API that does the real work.

Converting the gdk-pixbuf loader to Rust seems like writing a little glue code for the loadable module; the actual loading is just a couple of calls to librsvg's API.

Rsvg-rs in rsvg?

Converting the tests to Rust... ideally this would use the rsvg-rs bindings; for example, it is what I already use for rsvg-bench, a benchmarking program for librsvg.

I have an unfinished branch to merge the rsvg-rs repository into librsvg's own repository. This is because...

1. Librsvg builds its library, librsvg.so
2. Gobject-introspection runs on librsvg.so and the source code, and produces librsvg.gir
3. Rsvg-rs's build system calls gir on librsvg.gir to generate the Rust binding's code.

As you can imagine, doing all of this with Autotools is... rather convoluted. It gives me a lot of anxiety to think that there is also an unfinished branch to port the build system to Meson, where probably doing the .so→.gir→rs chain would be easier, but who knows. Help in this area is much appreciated!

An alternative?

Rustified tests could, of course, call the C API of librsvg by hand, in unsafe code. This may not be idiomatic, but sounds like it could be done relatively quickly.

Future work

There are two options to get rid of all the C code in the library, and just leave C header files for public consumption:

1. Do the GObject implementation in Rust, using Sebastian Dröge's work from GStreamer to do this easily.

2. Work on making gnome-class powerful enough to implement the librsvg API directly, and in an ABI-compatible fashion to what there is right now.

The second case will probably build upon the first one, since one of my plans for gnome-class is to make it generate code that uses Sebastian's, instead of generating all the GObject boilerplate by hand.

10 Jan 2019 6:28pm GMT

I remember some time ago discussing with someone from GNOME how important is to make a good issue report, the conclusion came along the lines of "I have 10 seconds to read per issue, if the issue is not well done it's most likely I won't have time to read it". It's true most of us are focused on doing actual code, after all it's what most of us enjoy and/or what we are paid for. So bug handling always takes a quite back place on our priorities.

On the other hand, the management of issues is neccessary for a healthy project, specially if you are using it for planification, prioritization, feedback gatherer and interaction with other developers or teams. In general, a set of open issues that is representative, updated and properly reported helps the project progress and build a community around.

Handling issues automatically

There are a set of tasks that are quite repetitive, such as closing issues that were left with the "need information" label. Or old feature requests. Or crashes that were reported years ago with an old version of the software…

This is something I really wanted to get done with, so I've been working in the past weeks to make a set up where repetitive tasks are automated by a GitLab CI "bot", and this is what I'm gonna share with you today!

The tool that performs the task is used by GitLab CE itself for their own issue triage automation and it's called gitlab-triage. This tool takes a set of rules and process them with a CI job, then you can set to be run periodically in schedules.

So let's take a look how to make a simple set up.

Basic set up

First, you need to set up a CI job that will run the tool. For that, in your CI file add:

triage:
  image: ruby:2.4
  stage: triage
  script:
    - gem install gitlab-triage
    - gitlab-triage --token $TRIAGE_BOT_TOKEN --project-id $CI_PROJECT_PATH --host-url https://gitlab.gnome.org
  only:
    - schedules

And add a "triage" stage to the file stages. This will install a ruby docker image, install the gitlab-triage program and then run it on schedules. Note the variable $TRIAGE_BOT_TOKEN, this is the API token of the account you want to use for perform the actions. You can use your account, a new account, or the bot I created for GNOME. Feel free to ask me the token for your use. Also, make sure the project has a schedule that the triage can run on.

Now, what it should run tho? That's where the policies file enters the game.

The policies

gitlab-triage will process a file called .triage-policies.yml on the root of your project. This file defines with what rules and what the bot should do. You can make conditions based on labels, dates, etc. Feel free to take a look at the gitlab-triage documentation, it's quite extense and helpful.

For now, let's write our first rule. And we are going with the less controversial one, closing issues that were marked as need information.

Close issues that need information and weren't updated

When a bug needs information to be properly triaged, we mark issues with the "need information" label. After some time, if nobody provides the information the bug should be closed. At GNOME Bugzilla we were closing these bugs after 6 weeks, with a stock answer .

How can we write this so it's done by the gitlab-triage bot? We just create a new rule in the policy file, in this way:

 resource_rules:
  issues:
    rules:
     - name: Close issues that need information and weren't updated 
        conditions:
          date:
            attribute: updated_at
            condition: older_than
            interval_type: weeks
            interval: 6
          state: opened
          labels:
            - 2. Needs Information 
        actions:
          status: close
          labels:
            - 15. Auto Updated
          comment: |
            Closing this issue as no further information or feedback has been provided.

            Please feel free to reopen this issue if you can provide the information or feedback.

            Thanks for your help!

            ---

            This is an automatic message. If you have suggestions to improve this automatic action feel free to add a comment on https://gitlab.gnome.org/GNOME/nautilus/issues/715

Quite simple. We set up the conditions that an issue must match in order to be processed under "conditions", then we set the actions we want to do to those issues in the "actions" section.

In this case, if an issue was last updated more than 6 weeks ago, it's in the opened state, and has the label "2. Needs Information" it will close the issue, set the label "15. Auto Updated" and comment the stock response. Note that we set a label to know that it was autoupdated by a bot, so in case something goes wrong we can query those issues and perform other actions on them.

You can see an example result here, it looks like:

And an example of a query for Nautilus auto updated issues here, which looks like:

Nice, right?

Close old feature proposals

Features proposals are probably the issues that has a higher ratio of being ignored. With the resources we usually have, it's unlikely we can add more maintainership "cost" to our projects, or that we already didn't plan carefully what features to add.

With this at hand, we want a rule that closes old feature proposals that hasn't been marked as part of the project planning. The rule looks like:

- name: Close old feature proposals without planning labels or milestones
  conditions:
    date:
      attribute: created_at
      condition: older_than
      interval_type: months
      interval: 12
    labels:
      - 1. Feature
    forbidden_labels:
      - 2. Deliverable
      - 2. Stretch
      - 1. Epic
    milestone:
      - No Milestone
    state: opened
    upvotes:
      attribute: upvotes
      condition: less_than
      threshold: 10
  actions:
    labels:
      - 15. Auto Updated
    status: close
    comment: |
      Hi,

      First of all, thank you for raising an issue to help improving Nautilus. In order to maintain order in the issue tracker we are closing old, unscheduled feature proposals.

      Unfortunately, no Merge Request has been provided for this, and/or the project contributors are not planning this feature in the foreseeable future.

      This issue will be closed as it meets the following criteria:
      * Created more than 12 months ago
      * Labeled as ~"1. Feature"
      * Not associated with a milestone or with ~"2. Deliverable" or ~"2. Stretch" project planning labels.
      
      Thanks for your help!

      ---

      This is an automatic message. If you have suggestions to improve this automatic action feel free to add a comment on https://gitlab.gnome.org/GNOME/nautilus/issues/715

It's similar to the previous rule, we just added the condition to not proccess issues that has the project planing labels "2. Deliverable", "2. Stretch" or "1. Epic". The project planning labels comes from the Project Planning for GNOME post.

Note the voting threshold condition of 10 votes, this is just an internal way to make sure we don't close automatically a highly voted feature proposal, so we rather make a manual comment to avoid misscomunications.

You can see an example result here, it looks like:

Bring attention to untriaged issues

This is all nice, but what about issues that wasn't even triagged in the first place? For those, we can make the bot create a summary for us. This helps greatly to bring to our attention in a regular basis those issues that need to be taken care of.

We use the "summarize" action, the rule looks like:

- name: Mark stale unlabelled issues for triage
  conditions:
    date:
      attribute: created_at
      condition: older_than
      interval_type: months
      interval: 2
    # We want to handle those that doesn't have these labels, including those with other labels.
    forbidden_labels:
      - 1. Bug
      - 1. Crash
      - 1. Epic
      - 1. Feature
    state: opened
  actions:
    labels:
      - 15. Untriaged
    summarize:
      title: Issues that need triaging
      item: |
        - {{web_url}} - {{title}} - {{labels}}
      summary: |
        The following issues were created two months ago and they are unlabeled:

        {{items}}

        /cc @Teams/BugSquad

This will create an issue with a list of issues that are lacking one of the labels listed in "forbidden_labels". Note that we could have use simply "No Label" value as a condition in a "Labels" section, however we wanted to bring to our attention those issues that have other labels but we didn't mark if they were a bug or a feature, because we rely on these labels for the previous rules.

Also note that the created issue pings a group called "Teams/BugSquad", which doesn't exist yet. If this sounds useful for us, I would like to create this group so bug triagers can be part of that group and get pinged to handle these issues in a regular basis.

You can see an example result here, it looks like:

Close old issues

This is a controversial one. Who hasn't receive a "Fedora has reached EOL" mass mails? :) I will leave the explanation why I think we should try this for another post, since here I want to focus on providing just the tooling and snippets for those who want to try it out.

For closing old bugs we just look at the updated date and close those that hasn't been touched in 18 months.

- name: Close stale issues with no milestone or planning labels
  conditions:
    date:
      attribute: updated_at
      condition: older_than
      interval_type: months
      interval: 18
    milestone:
      - No Milestone
    forbidden_labels:
      - 2. Deliverable
      - 2. Stretch
      - 1. Epic
      # Features are handled in a different rule
      - 1. Feature
    state: opened
  actions:
    status: close
    labels:
      - 15. Auto Updated
    comment: |
      Hi,

      Thank you for raising an issue to help improve Nautilus. We're sorry this particular issue has gone unnoticed for quite some time.

      This issue will be closed, as it meets the following criteria:
      * No activity in the past 18 months (3 releases).
      * Unscheduled. Not associated with a milestone or with ~"2. Deliverable" or ~"2. Stretch" project planning labels.

      We'd like to ask you to help us keep our issue tracker organized  by determining whether this issue should be reopened.

      If this issue is reporting a bug, let us know if this issue is still present in a newer version and if you can reproduce it in the [nightly version](https://wiki.gnome.org/Apps/Nightly).

      Thanks for your help!

      ---

      This is an automatic message. If you have suggestions to improve this automatic action feel free to add a comment on https://gitlab.gnome.org/GNOME/nautilus/issues/715

Let me know how it works for you

So far it has work quite well for Nautilus, in our first run it helped us to triage around 50 issues, and the bot closes 15 issues that were either waiting long for information or were old features requests.

These rules can be tweaked, and in general these are an approach I think we should test. There are a few things that are a bit bold, specially closing issues automatically, so any feedback is appreciated.

I'm looking forward to hear how it works for you, and see if there are other modifications you do or some advice you would propose.

Enjoy!

10 Jan 2019 5:08pm GMT

Just like AMI, Phoenix is a huge firmware vendor, providing the firmware for millions of machines. If you're using a ThinkPad right now, you're most probably using Phoenix code in your mainboard firmware. Phoenix have been working with Lenovo and their ODMs on LVFS support for a while, fixing all the niggles that was stopping the capsule from working with the loader used by Linux. Phoenix can help customers build deliverables for the LVFS that use UX capsule support to make flashing beautiful, although it's up to the OEM if that's used or not.

It might seem slightly odd for me to be working with the firmware suppliers, rather than just OEMs, but I'm actually just doing both in parallel. From my point of view, both of the biggest firmware suppliers now understand the LVFS, and provide standards-compliant capsules by default. This should hopefully mean smaller Linux-specific OEMs like Tuxedo and Star Labs might be able to get signed UEFI capsules, rather than just getting a ROM file and an unsigned loader.

We're still waiting for the last remaining huge OEM, but fingers crossed that should be any day now.

09 Jan 2019 2:21pm GMT

Last week I finally found some time to add the automation mode to Epiphany, that allows to run automated tests using WebDriver. It's important to note that the automation mode is not expected to be used by users or applications to control the browser remotely, but only by WebDriver automated tests. For that reason, the automation mode is incompatible with a primary user profile. There are a few other things affected by the auotmation mode:

• There's no persistency. A private profile is created in tmp and only ephemeral web contexts are used.
• URL entry is not editable, since users are not expected to interact with the browser.
• An info bar is shown to notify the user that the browser is being controlled by automation.
• The window decoration is orange to make it even clearer that the browser is running in automation mode.

So, how can I write tests to be run in Epiphany? First, you need to install a recently enough selenium. For now, only the python API is supported. Selenium doesn't have an Epiphany driver, but the WebKitGTK driver can be used with any WebKitGTK+ based browser, by providing the browser information as part of session capabilities.

from selenium import webdriver

options = webdriver.WebKitGTKOptions()
options.binary_location = 'epiphany'
options.add_argument('--automation-mode')
options.set_capability('browserName', 'Epiphany')
options.set_capability('version', '3.31.4')

ephy = webdriver.WebKitGTK(options=options, desired_capabilities={})
ephy.get('http://www.webkitgtk.org')
ephy.quit()

This is a very simple example that just opens Epiphany in automation mode, loads http://www.webkitgtk.org and closes Epiphany. A few comments about the example:

• Version 3.31.4 will be the first one including the automation mode.
• The parameter desired_capabilities shouldn't be needed, but there's a bug in selenium that has been fixed very recently.
• WebKitGTKOptions.set_capability was added in selenium 3.14, if you have an older version you can use the following snippet instead

from selenium import webdriver

options = webdriver.WebKitGTKOptions()
options.binary_location = 'epiphany'
options.add_argument('--automation-mode')
capabilities = options.to_capabilities()
capabilities['browserName'] = 'Epiphany'
capabilities['version'] = '3.31.4'

ephy = webdriver.WebKitGTK(desired_capabilities=capabilities)
ephy.get('http://www.webkitgtk.org')
ephy.quit()

To simplify the driver instantation you can create your own Epiphany driver derived from the WebKitGTK one:

from selenium import webdriver

class Epiphany(webdriver.WebKitGTK):
    def __init__(self):
        options = webdriver.WebKitGTKOptions()
        options.binary_location = 'epiphany'
        options.add_argument('--automation-mode')
        options.set_capability('browserName', 'Epiphany')
        options.set_capability('version', '3.31.4')

        webdriver.WebKitGTK.__init__(self, options=options, desired_capabilities={})

ephy = Epiphany()
ephy.get('http://www.webkitgtk.org')
ephy.quit()

The same for selenium < 3.14

from selenium import webdriver

class Epiphany(webdriver.WebKitGTK):
    def __init__(self):
        options = webdriver.WebKitGTKOptions()
        options.binary_location = 'epiphany'
        options.add_argument('--automation-mode')
        capabilities = options.to_capabilities()
        capabilities['browserName'] = 'Epiphany'
        capabilities['version'] = '3.31.4'

        webdriver.WebKitGTK.__init__(self, desired_capabilities=capabilities)

ephy = Epiphany()
ephy.get('http://www.webkitgtk.org')
ephy.quit()

08 Jan 2019 5:36pm GMT

This continues, and concludes a series of items on Vendor Neutral FLOSS projects and how they do marketing which you can read here.

TDF / LibreOffice Branding

If we want to grow our community, and to drive this with marketing - we need to position our brands to make this easy and ideally unconscious. Currently we have two brands, taking the descriptions from their websites:

• LibreOffice is Free and Open Source Software Development is open to new talent and new ideas, and our software is tested and used daily by a large and devoted user community (link).
  • ie. it is pretty clear: 'LibreOffice' is software.
• The Document Foundation - It is an independent self-governing meritocratic entity, created by a large group of Free Software advocates, in the form of a charitable Foundation under German law (gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts). (link).
  • ie. it is clear this is a Stiftung - and by association / default comes to also mean the handful of employees who comprise the paid team there with some oversight from the board.

Unfortunately - it seems we have two brands, and neither of these means "The community", or "The people who do most of the hard work". These are the people we need to be encouraging, recruiting, building up, and talking about. The degree to which TDF's paid staff represent 'the community' is unclear. The board is elected to represent the community, and oversees TDF but is also not itself the community (but the board). When TDF says "our software" - how can we ensure that everyone feels included in that 'our' ?

It seems clear that we need to solve this dis-connection with some formulation, strap-line, brand or form of words that we use to highlight and emphasize our contributor's input - and use this repeatedly.

LibreOffice vs. Commercial branding

Branding is really important as we have seen: shipping identical software, at the same price in the Mac app store with just the LibreOffice vs. Collabora Office brand changed shows - that the LibreOffice brand is simply far better known & sought after gathering the overwhelming majority of interest. This however brings a problem - if development work is funded by leads generated from brands then TDF promoting eg. LibreOffice Online under its own brand can easily radically impair leads, investment and thus code-flows into LibreOffice Online without any offsetting advantage. The picture below compares two branding approaches for the 95%+ of commits that Collabora has put into LibreOffice Online. The 0.05% is the proportion of visitors to LibreOffice that discover that they should fund development buying professional services (from anyone) - as we shall see below.

TDF marketing in practice

How does LibreOffice get marketed from this perspective ? How do companies get leads from TDF so that they can sell to some fraction of them their products, support & services thus allowing re-investment back into LibreOffice ? Answer: very poorly. Recently we've done a better job of telling people about LibreOffice, a recent release announcement says:

"LibreOffice 6.1's new features have been developed by a large community of code contributors: 72% of commits are from developers employed by companies sitting in the Advisory Board like Collabora, Red Hat and CIB and by other contributors such as SIL and Pardus, and 28% are from individual volunteers."

and also encourages people to use an LTS version - which is not itself provided by TDF - which is a major improvement:

"For any enterprise class deployment, TDF maintains the more mature LibreOffice 6.0, which should be sourced from a company providing a Long Term Supported version of the suite (they are all members of TDF Advisory Board, and are listed here: http://www.documentfoundation.org/governance/advisory-board/)."

However the website still has a large number of issues in this area, investing nominal fees into Advisory Board membership is a marginal contribution vs. the substantial investments into the software & community. A better approach is the single page that educates users about the availability of professional services - which is the get-help/professional-support/ page which highlights certified competent migraators, trainers and developers. So how does this hero list of contributors to LibreOffice's success fare when people visit our site, lets see by checking out the metrics on page visits:

It is interesting to see that those interested in professional support - only around 4700 this year (1/3rd of 13000) exited to either close the session, or visit a supported version provider. The bounce rate suggests that the majority of people arrive on the professional support page from elsewhere, and not TDF's own properties. This matches with what is seen by vendors analyzing what arrives from TDF. Compared with the total visits as of (2018-09-07):

the number of people exiting to find professional service from that page is 0.05% of our 9.5 million visitors so far.

The contrast between the "Economic and code contribution flows in today's ecosystem" and even the helpful description in the 6.1 release marketing acknowledging 72% of commits, compared with the 0.05% actual click-through rate is extraordinarily stark. It seems clear that our users are not being educated as to the importance of supporting the certified ecosystem - certainly in the area of code, but almost certainly also in other certified areas such as training & migration.

Visualizing 0.05%

This is rather a tricky task - it rapidly turns into something like visualizing the geometry and distances of the solar system. Two charts are shown - a pie chart with the corporate contribution to the code in commits - and a crop to the center of another showing the flow of people clicking through the page to find professional services which go to 1improve LibreOffice (in blue) and others in red:

It is of course unclear what %age of our visitors are enterprises and thus should be encouraged to seek professional help, however 0.05% seems an implausibly low fraction by perhaps two orders of magnitude.

Marketing - Product expectations

Another side-effect of majoring on LibreOffice as a free, always and forever and for everyone free, no catches, product - is creating mistaken expectations in our users around how the relationship works. Here is a simple example mail from 2018-04-19:

"Please help me to installLibreOffice at Lubuntu17
 my donation number via PayPal is 1TV07632F2376242R"

Apparently the donor believes there is some connection between his donation and installation support, despite our donate page being quite explicit that this is not so. This is buttressed by rather regular E-mails of the form I made my donation, but still can't download it - apparently people love to miss the LibreOffice is Free Software and is made available free of charge. Your donation, which is purely optional, supports our worldwide community. text there.

This example is relatively friendly. Some chunk of user interactions are much less friendly - criticizing the product, attacking the project for not fixing their particular issue on their timeline, or investing in their particular problem. A peripheral, but amusing pathology is of users from time to time augmenting the urgency of a request by generously offering a $50 donation to TDF to cover the (often) multiple-person-week of (pet) feature work needed.

By setting a more realistic expectation around support, enterprise suitability , and particularly by encouraging people on our main properties to contribute - it is possible to build a consumer, community brand - rather than a pure product brand. This may have a positive impact on reducing the feeling of entitlement that some of our users have.

Similarly enterprises deploy the wrong software, without support, fail to keep it up-to-date, and then believe that we are responsible for helping them, a recent mail to the security list highlights this, names removed to protect the mislead:

Subject: Security issues within Libre Office
My Company, XXXXX, uses the latest ( I think ) version of Libre Office.
We also use the Qualys tool for security Compliance. It has found a vulnerability
with Libre Office. Are you familiar with this, And how do I remediate your application?

... signature reads ...

FORTUNE Magazine World's Most Admired Companies® 2014|2015|2016|2017|2018

A kind reply, funded by RedHat's formidable security investment:

It might be that its already fixed in the latest stable release, or its
a false positive, or even something that remains to be fixed, but we'd
need more information to judge.

And then we find out:

The version we have is:
C:\Program Files (x86)\LibreOffice 4\program\soffice.exe Version is 4.2.0.4
Have you found similar vulnerabilites? Is there a newer version that we can
download and test against the above reported vulnerabilities.

They use a version that is four years old today, and this is from a significant company, saving plenty of money and apparently investing nothing - instead, consuming time from those who are. Far from an isolated example, some of them are ruder with a more explicit sense of entitlement.

Our marketing - setting expectations

The software industry is an industry typically driven by hype, where software startup marketing has this rather 'visionary' approach, something like:

This could be called the Sagrada Familia model, as long as people know this is what they're buying it has a certain logic. Arguably TDF's current marketing has a leaning towards:

Almost certainly a more helpful marketing approach might be:

The experience of selling a supported LibreOffice

Against this - the experience of selling a supported version of LibreOffice is hard. LibreOffice has a powerful brand, and it is associated with everything being free as in beer. Some small subset of our community appear to believe that building product brands and businesses around LibreOffice is non-ideal, and that we should focus on providing ever more services free to enterprises. The perception that the 'genuine' version is LibreOffice from TDF is real one, and stoked by the lack of systematic acknowledgment of the great benefits provided by the ecosystem.

Contributors are sometimes deeply emotionally attached to the project, and the LibreOffice brand and feel that to promote an alternative brand, even if in doing so that helps fund the work, is some sort of betrayal - or lack of neutrality. This sometimes extends to being eager to duplicate functionality, packaging, documentation etc. simply to re-brand it to LibreOffice.

This too is profoundly unfortunate. Others believe that FLOSS is fundamentally identified with a zero per-seat cost - perhaps plus some consultancy (perhaps installation, or some migration support), and that having no SLA, and letting others fund long term product investment is the only sensible approach to choose: maximising their apparent saving. Discussions with such parties are quite interesting - often oscillating between variants of: "I should pay nothing per seat because its FLOSS", and "The product is not yet quite good enough for us - you must fix it for free before we [don't] buy your product".

It would be good to have TDF's explicit support for selling branded support services and versions around LibreOffice to make this more socially obvious to those who are not members of our community.

Conclusions

The commercial ecosystem around LibreOffice is an un-necessarily tough environment to operate in. Companies contribute a large proportion of the work, and yet get very little acknowledgement - which in turn makes it hard for them to invest. This also creates an un-necessary tension with companies marketing - which has to focus on building their own brands. Companies should not fear the arrival of the LibreOffice brand to squash, claim credit for, and present their work as created by someone else - thus effectively depriving them of leads. This is unsustainable.

The LibreOffice project should give a new focus to promoting and celebrating all participants in its community - including ecosystem companies. This is far from a problem unique to companies. It is routinely the case that individual community members feel under-appreciated - they would like more recognition of their work, and promotion of their own personal public brands as valued contributors. This is something that TDF should re-balance its marketing resource into, in preference to product marketing.

The LibreOffice project should explicitly create space for enterprise distributions by explicitly pointing out the weaknesses of LibreOffice for enterprises on its hot marketing properties. This would have a positive effect of encouraging companies to acknowledge and build the LibreOffice brand safe in the knowledge that anyone visiting LibreOffice will get an accurate and balanced picture of their skills and contribution.

We badly need to increase diverse investment into our ecosystem by building an environment where deep investment into LibreOffice is a sound economic choice: economics ultimately drives ecosystem behavior. By creating the right environment - often not by acting, but by clearly and deliberately not acting in a space - we can build a virtuous circle of investment that produces ever better software that meets TDF's mission.

It has been said that in life - "You can either achieve things, or get the credit". Unfortunately, in the world of FLOSS - in order to sustainably achieve things you need to get the credit (and associated leads and hence sales). During the early creation of the project it was strategically necessary to under-emphasize corporate involvement, particularly of SUSE heavy lifting - but these days are long past. Similarly, we need to build a brand or formulation that stands for all volunteer contributors to LibreOffice and acknowledge these fulsomely.

This is the state of play today in the LibreOffice world, but the good news is, this is just the background for a series of positive discussions and suggested actions to re-balance TDF's marketing. No significant change is proposed to our development process, timeline, branching etc. I believe most of these are common-sense, and should be supported by the majority of the outside community, as well as those involved with the project - who have a more intuitive feel of the balance here. Some suggestions may be relevant to vendor neutral non-profits; but most are specific to LibreOffice. My plan is to post those suggestions to our public Marketing list and to have an open discussion there of how best to balance this. Potentially I'll add a summary here later.

Thanks for reading - perhaps this may help some other communities improve their ecosystems too. For those interested in the source for my drawings they are available

Postscript to marketers

This paper has focused heavily on ways to improve our marketing and messaging. If you read this far - thank you ! It should in no way be read as a personal critique of people doing our marketing. Our existing positioning and approach and direction is something that has accumulated over many years, and all in leadership in the project are responsible for where we are at now. If you work in marketiing - thank-you for all you do, and the many positive messages that get out. Hopefully with some adjustments we can grow the project in exciting new directions at some large multiple of its current trajectory for the benefit of all.

This way - I hope we can meet the dream of gaining wider acceptance in the enterprise market.

08 Jan 2019 2:46pm GMT

• Poked at vendor neutral marketing bits and updated some pictures; mail chew, pleased to get a Purchase Order six months after signing a contract, nice.

08 Jan 2019 2:29pm GMT