FOSDEM 2017 From the community devroom

A few weeks ago I happily went off to FOSDEM. Saturday I caught up with people, Sunday I spent most of the day in the incredibly busy Community devroom - right until I had to give up my seat for food. I really enjoyed the talks and hope the track manages to get a bigger devroom next year, dozens of people had to be kept out after every session ended (fire safety regulations).

Most talks lasted about 30mn and the videos should be available on the FOSDEM website. Here are some of the highlights from my perspective and notes.

Closing Loops (Greg Sutcliffe)

Link to talk

This talk was more about raising questions and figuring out best practices based on audience participation rather than offering The One Solution. In this context, a "loop" means an RFC still undecided, a discussion dying out, patches unreviewed. How do you decide when a topic has come to a conclusion?

It's important to remember that everybody has the best interests of the project at heart, this is more about blaming the systems we use.

Say, in a Request For Comments discussing significant changes on a mailing list, the discussion tends to peter out after a while, and it can be difficult to track how a proposal evolved. Foreman (Greg's project) decided to move the discussions to an RFC repository instead, but 6 months later it seems to have only moved the problem.

From the audience:

  • For Debian, the discussion ends "when someone starts the work" :)
  • LibreOffice has a "technical council" type meeting/discussion with about 40 people, on the phone. A wiki documents the process to join.
  • In the PHP world, the RFC author gets to choose when to call a vote and the deadline for it (at least 2 weeks ahead). Greg wondered if that might get divisive if there are too many 50/50 situations, but the audience member indicated that it wasn't the case, because most problems get solved during the discussions that precede the vote so they are usually overwhelmingly accepted. Every contributor gets a vote from a certain contribution threshold.

The speaker seemed interested in trying out the technical council direction for his project.

Data science for community management (Manrique Lopez)

Link to talk

Communities need to have a common vision and self-awareness to see if they are walking toward it: what kind of people are part of the community, what are they doing... This helps with governance and transparency (fairness, trust).

What is the role of a community manager? Do communities even need to be managed? "Manage" is a strong word.

A community manager is interested in keeping their community alive, active, and productive. Having visibility into community health is important. There are a lot of tools out there with data relevant to this: JIRA, git, IRC, slack, StackOverflow, ... A lot of places, which individually are only one part of the bigger picture.

Rather than cobling a bunch of scripts together to get to all that data, GrimoireLab does all the work for you and presents it nicely using graphs. One example was the "Pony Factor," which I hadn't heard of: who's doing 50% of the commits? For example in the kernel, the pony factor is about 200 people/10 companies. That's a lot of people!

When you have that data you can see the evolution of the project over time: reviews, gender, demography, pony factor, etc, etc., in beta, lets you try it out for free for up to 5 Github organisations.

Getting your issues fixed (Tomer Brisker)

Link to talk

I think anyone trying to get help or start contributing as a user to an open-source project needs to watch this. Tomer summarised a ton of best practices that experienced open-source people "just know" and would likely never think to document.

A super rough summary:

  • Try to ask for help on IRC
  • Try the mailing list. If no one replies and you solve it yourself or find a workaround later, please self-reply. (Mandatory xkcd link)
  • Search the bug tracker. If there is a bug, add your input, your use case. If there are none, create a new issue and include as much information as possible: traces, logs, version (including of the plugin if relevant), screenshots... Anything to help the developers reproduce the issue. If this is a feature request, explain your use case.


  • Tabs vs spaces: follow the coding guidelines for the project. If there aren't any follow the standards and conventions of the existing code base.
  • Make the commit message good. Explain "why" as completely as possible. Apparently Github even lets you include screenshots, so that the patch can be reviewed without having to pull the code. "Why" did you do it this way and not another way, explained in such a way people in the future can understand the decision.
  • Include tests. This protects against regressions, so that you don't have to fix the same bug two releases later.
  • Be kind. We're building a community. No one wants to be shouted at. Be patient.

Handle conflict, like a boss! (Deb Nicholson)

Link to talk

Conflicts often come from a piece of information that is missing. Conflict is natural. If you don't handle it, it will come back worse.

How do we minimise it? Try to understand the other people, where they're coming from.

For example:

  • Passion. When people get so excited about something they forget why they're doing it. Mismatched goals.
  • Identity. When someone's identity is linked to a task, not a goal. For example, the person known to be super helpful with wrangling the complex bug tracker, who'll end up sad when you finally upgrade to something better.

Don't leave conflict unattended or you'll end up in a snake pit. You don't owe your mental health to any FOSS project.

There are 3 styles of handling conflict. We tend to use them all, depending on the circumstances.

  • Avoidance. This is not good in a project! It festers. It looks like you don't care, like you're not connected to the community and its concerns.
  • Accommodation. Doing stuff you don't really want to in order to keep the group happy. For bigger issues it can make it look like you don't mind the way things are going. It works for small things.
  • Assertion. Can also be called Aggression. Name calling, etc. Not a good strategy. It wears out other contributors.

Conversations happen in many places. Document the decisions so that it doesn't feel like they're coming out of nowhere.

If you notice in passing a problem in the community you're probably missing some information. Gather more info in order to understand the source of conflict: misunderstanding goals, stepping on toes (e.g. that person always writes the release notes but someone else went ahead and did it this time instead, without asking), ... Is it new members clashing with the old ones? Go back to the historical vision, step out of the tactical discussion. Are there sekrit goals underway? For example a motivation you're not aware of, someone with different goals for their participation like a new job or internal deadlines...

If the conflict is based on fear, it can be harder to get at, e.g. someone afraid they can't learn a new skill if switching language. Create a back channel where it's safe to discuss, to try to deal with it.

Planning for future conflict:

  • Assume the best.
  • Have a code of conduct. Set expectations.
  • No name calling/ad hominem, only discuss technical merits.
  • Set an example.

We could do so much more in the FOSS world if we didn't spend so much time slagging each other :)

Some references:

Mentoring 101 (Brian Proffitt)

Link to talk

This was a lively talk on both formal mentoring via programs such as the Google Summer of Code as well as daily mentoring.

Onboarding is important. This is not just about keeping people in but helping people get in.

As software project, should you want to participate in formal mentoring: have a plan. Formal programs have their own rules and structure.

As a participant, be a member of the community, pick a project that interests you. Be ready to commit. Be flexible - it takes time but is rewarding. Be ready to ask for help.

Undermentoring is a problem. Have clear, set goals for the mentee. Keep an eye on them while also giving them space.

Issue with mentees disappearing... They really should keep a line of communication open, even if only to say, "sorry, I cant' participate anymore." (From personal experience mentoring, this is quite stressful and it was a relief when the mentee admitted they could no longer participate.) You need to proactively mentor to avoid this.

  • Be consistent. E.g. your style may be authoritative (do it this way), democratic (collaboration) or coaching (guidance). Stick to one. (...with Brian noting that the last one is best for mentoring!)
  • Set expectations. Make sure the goals are aligned, define the process, avoid confusion.
  • Take an interest in the mentee. Listen actively. Build a relationship. Learn their style. Don't be a stalker though.
  • Wait before giving advice. It's easy to try to fix things when someone comes at you with a problem. You might be able to solve it but that won't help them. Hit the pause button. Ask more question, get to the heart, guide them to the solution. It takes time. You may not solve the problem. As long as it's not time-sensitive that's ok.
  • Don't assume anything. Avoid stereotypes. Learn the details of a situation. Emphasise communication.

Remember this one thing: they aren't you!! Understand the mentee. This is not only about getting the project done.

A question from the audience was, how can I help my mentor as a mentee? Once again it's about being proactive: this is what I want to do, how do you help me do this? If it isn't working, reconsider the relationship.

How to recruit mentors? Some projects are easier to get in than others. In oVirt, there's a separate mailing list and no formal process. Spread the word, see who's interested. What about a project where there's a lot of mentees yet no one ever answers the call for mentors? If this is part of a corporate project, a solution could be to make it part of the job.

Impromptu community talk

One of the talks was cancelled, so a couple of people started a conversation around community and community events (too many pizzas, too much alcohol is the feedback I remember from that part).

The need for "cruel empathy" was brought up: sometimes meeting organisers should be jerks for good reasons. Loud, demeaning people are toxic and need to be called out. Tell them, in private: "I appreciate that you're here, etc, but you're sucking air out of the community." They may not realise they are doing it, so be nice about it.

The Shotwell community was brought up as one with great first contact.

Overcoming culture clash (Dave Neary)

Link to talk

This was a very interesting talk, mainly summarising information and graphs from books, which I'm going to list here. And hopefully read soon!

Basically a lot of what we do and how we interpret things depends on our upbringing (country, culture, ...)

  • The Tragedy of the Commons - Garret Hardin.
  • Moral Tribes - Joshua Greene.
  • Culture and Organizations - Geert Hofstede. That one brings up 6 dimensions of culture, for example tending to be uncomfortable with silence and filling it instantly, vs. leaving a couple seconds pause to make sure the person is finished.
  • Getting to Yes - Roger Fish. This is more psychology-based than about hard negotiation.

There are no easy solutions. Focus on the relationship. Take small steps: one conversation at a time. Encourage local user groups - though keep them connected e.g. via sending mentors/leaders to these meetups to avoid silos. Have short mentoring programs. Learn about the cultural norms and sensitivity of the community. Avoid real-time meetings.

I contributed! But what now? (Bee Padalkar)

Link to talk

Based on the Fedora community, this talk was about improving contributor retention rates by finding patterns about successful contributors.

Why do people stay? According to a survey they ran, usually thanks to the strong, positive and inclusive community. Other reasons were identifying with the Fedora foundations (core values), giving back, constantly learning.

No matter how interesting the project is, if the community is poor people don't stick around.

  • Have a defined onboarding process.
  • Encourage people to speak up.
  • Assign action items early on, to create a sense of responsibility.
  • Let people know they are doing good work, give feedback (e.g. IRC karma).
  • Use inclusive and motivating language.
  • Encourage attending events to meet people in person.
  • Encourage consistency over activity. Let people contribute according to their own time.
  • Inspire, interact, give feedback.
  • Help people identify with your mission.


Looking forward to next year's event!

Leave a comment

A Quick Introduction to Mistral Usage in TripleO (Newton) For developers

Since Newton, Mistral has become a central component to the TripleO project, handling many of the operations in the back-end. I recently gave a short crash course on Mistral, what it is and how we use it to a few people and thought it might be useful to share some of my bag of tricks here as well.

What is Mistral?

It's a workflow service. You describe what you want as a series of steps (tasks) in YAML, and it will coordinate things for you, usually asynchronously.

Link: Mistral overview.

We are using it for a few reasons:

  • it lets us manage long-running processes (e.g. introspection) and track their state
  • it acts a common interface/API, that is currently used by both the TripleO CLI and UI thus avoiding duplication, and can also be consumed directly by external non-OpenStack consumers (e.g. ManageIQ).


A workbook contains multiple workflows. (The TripleO workbooks live at

A workflow contains a series of 'tasks' which can be thought of as steps. We use the default 'direct' type of workflow on TripleO, which means tasks are executed in the order written, moving around based on the on-success and on-error values.

Every task calls to an action (or to another workflow), which is where the work actually gets done.

OpenStack services are automatically mapped into actions thanks to the mappings defined in Mistral, so we get a ton of actions for free already.

Useful tip: with the following commands you can see locally which actions are available, for a given project.

$ mistral action-list | grep $projectname

You can of course create your own actions. Which we do. Quite a lot.

$ mistral action-list | grep tripleo

An execution is what an instance of a running workflow is called, once you started one.

Link: Mistral terminology (very detailed, with diagrams and examples).

Where the TripleO Mistral workflows live

Let's look at a couple of examples.

A short one to start with, scaling down

It takes some input, starts with the 'delete_node' task and continues on to on-success or on-error depending on the action result.

Note: You can see we always end the workflow with send_message, which is a convention we use in the project. Even if an action failed and moves to on-error, the workflow itself should be successful (a failed workflow would indicate a problem at the Mistral level). We end with send_message because we want to let the caller know what was the result.

How will the consumer get to that result? We associate every workflow with a Zaqar queue. This is a TripleO convention, not a Mistral requirement. Each of our workflow takes a queue_name as input, and the clients are expected to listen to the Zaqar socket for that queue in order to receive the messages.

Another point, about the action itself on line 20: tripleo.scale.delete_node is a TripleO-specific action, as indicated in the name. If you were interested in finding the code for it, you should look at the entry_points in setup.cfg for tripleo-common (where all the workflows live):

which would lead you to the code at:

A bit more complex: node configuration

It's "slightly more complex" in that it has a couple more tasks, and it also calls to another workflow (line 426). You can see it starts with a call to ironic.node_list in its first task at line 417, which comes for free with Mistral. No need to reimplement it.

Debugging notes on workflows and Zaqar

Each workflow creates a Zaqar queue, to send progress information back to the client (CLI, web UI, other...).

Sometimes these messages get lost and the process hangs. It doesn't mean the action didn't complete successfully.

  • Check the Zaqar processes are up and running: $ sudo systemctl | grep zaqar (this has happened to me after reboots)
  • Check Mistral for any errored workflow: $ mistral execution-list
  • Check the Mistral logs (executor.log and engine.log are usually where the interesting errors are)
  • Ocata has timeouts for some of the commands now, so this is getting better

Following a workflow through its execution via CLI

This particular example will run somewhat fast so it's more of a "tracing back what happened afterwards."

$ openstack overcloud plan create my-new-overcloud
Started Mistral Workflow. Execution ID: 05d550f2-5d13-4782-be7f-a775a1d86a84
Default plan created

The CLI nicely tells you which execution ID to look for, so let's use it:

$ mistral task-list 05d550f2-5d13-4782-be7f-a775a1d86a84

| ID                                   | Name                            | Workflow name                              | Execution ID                         | State   | State info                   |
| c6e0fef0-4e65-4ee6-9ae4-a6d9e8451fd0 | verify_container_doesnt_exist   | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | ERROR   | Failed to run action [act... |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| 72c1310d-8379-4869-918e-62eb04530e46 | verify_environment_doesnt_exist | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | ERROR   | Failed to run action [act... |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| 74438300-8b18-40fd-bf73-62a1d90f71b3 | create_container                | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| 667c0e4b-6f6c-447d-9325-ab6c20c8ad98 | upload_to_container             | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| ef447ea6-86ec-4a62-bca2-a083c66f96d3 | create_plan                     | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| f37ebe9f-b39c-4f7a-9a60-eceb80782714 | ensure_passwords_exist          | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| 193f65fb-502a-4e4c-9a2d-053966500990 | plan_process_templates          | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| 400d7e11-aea8-45c7-96e8-c61523d66fe4 | plan_set_status_success         | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |
| 9df60103-15e2-442e-8dc5-ff0d61dba449 | notify_zaqar                    | tripleo.plan_management.v1.create_default_ | 05d550f2-5d13-4782-be7f-a775a1d86a84 | SUCCESS | None                         |
|                                      |                                 | deployment_plan                            |                                      |         |                              |

This gives you an idea of what Mistral did to accomplish the goal. You can also map it back to the workflow defined in tripleo-common to follow through the steps and find out what exactly was run. It if the workflow stopped too early, this can give you an idea of where the problem occurred.

Side-node about plans and the ERRORed tasks above

As of Newton, information about deployment is stored in a "Plan" which is implemented as a Swift container together with a Mistral environment. This could change in the future but for now that is what a plan is.

To create a new plan, we need to make sure there isn't already a container or an environment with that name. We could implement this in an action in Python, or since Mistral already has commands to get a container / get an environment we can be clever about this and reverse the on-error and on-success actions compared to usual:

If we do get a 'container' then it means it already exists and the plan already exists, so we cannot reuse this name. So 'on-success' becomes the error condition.

I sometimes regret a little us going this way because it leaves exception tracebacks in the logs, which is misleading when folks go to the Mistral logs for the first time in order to debug some other issue.

Finally I'd like to end all this by mentioning the Mistral Quick Start tutorial, which is excellent. It takes you from creating a very simple workflow to following its journey through the execution.

How to create your own action/workflow in TripleO

Mistral documentation:

In short:

  • Start writing your python code, probably under tripleo_common/actions
  • Add an entry point referencing it to setup.cfg
  • /!\ Restart Mistral /!\ Action code is only taken in once Mistral starts

This is summarised in the TripleO common README (personally I put this in a script to easily rerun it all).

Back to deployments: what's in a plan

As mentioned earlier, a plan is the combination of a as a Swift container + Mistral environment. In theory this is an implementation detail which shouldn't matter to deployers. In practice knowing this gives you access to a few more debugging tricks.

For example, the templates you initially provided will be accessible through Swift.

$ swift list $plan-name

Everything else will live in the Mistral environment. This contains:

  • The default passwords (which is a potential source of confusion)
  • The parameters_default aka overriden parameters (this takes priority and would override the passwords above)
  • The list of enabled environments (this looks nicer for plans created from the UI, as they are all munged into one user-environment.yaml file when deploying from CLI - see bug 1640861)
$ mistral environment-get $plan-name

For example, with an SSL-deployment done from the UI:

$ mistral environment-get ssl-overcloud
| Field       | Value                                                                             |
| Name        | ssl-overcloud                                                                     |
| Description | <none>                                                                            |
| Variables   | {                                                                                 |
|             |     "passwords": {                                                                |
|             |         "KeystoneFernetKey1": "V3Dqp9MLP0mFvK0C7q3HlIsGBAI5VM1aW9JJ6c5lLjo=",     |
|             |         "KeystoneFernetKey0": "ll6gbwcbhyAi9jNvBnpWDImMmEAaW5dog5nRQvzvEz4=",     |
|             |         "HAProxyStatsPassword": "NXgvwfJ23VHJmwFf2HmKMrgcw",                      |
|             |         "HeatPassword": "Fs7K3CxR636BFhyDJWjsbAQZr",                              |
|             |         "ManilaPassword": "Kya6gr2zp2x8ApD6wtwUUMcBs",                            |
|             |         "NeutronPassword": "x2YK6xMaYUtgn8KxyFCQXfzR6",                           |
|             |         "SnmpdReadonlyUserPassword": "5a81d2d83ee4b69b33587249abf49cd672d08541",  |
|             |         "GlancePassword": "pBdfTUqv3yxpH3BcPjrJwb9d9",                            |
|             |         "AdminPassword": "KGGz6ApEDGdngj3KMpy7M2QGu",                             |
|             |         "IronicPassword": "347ezHCEqpqhmANK4fpWK2MvN",                            |
|             |         "HeatStackDomainAdminPassword": "kUk6VNxe4FG8ECBvMC6C4rAqc",              |
|             |         "ZaqarPassword": "6WVc8XWFjuKFMy2qP2qqqVk82",                             |
|             |         "MysqlClustercheckPassword": "M8V26MfpJc8FmpG88zu7p3bpw",                 |
|             |         "GnocchiPassword": "3H6pmazAQnnHj24QXADxPrguM",                           |
|             |         "CephAdminKey": "AQDloEFYAAAAABAAcCT546pzZnkfCJBSRz4C9w==",               |
|             |         "CeilometerPassword": "6DfAKDFdEFhxWtm63TcwsEW2D",                        |
|             |         "CinderPassword": "R8DvNyVKaqA44wRKUXEWfc4YH",                            |
|             |         "RabbitPassword": "9NeRMdCyQhekJAh9zdXtMhZW7",                            |
|             |         "CephRgwKey": "AQDloEFYAAAAABAACIfOTgp3dxt3Sqn5OPhU4Q==",                 |
|             |         "TrovePassword": "GbpxyPdnJkUCjXu4AsjmgqZVv",                             |
|             |         "KeystoneCredential0": "1BNiiNQjthjaIBnJd3EtoihXu25ZCzAYsKBpPQaV12M=",    |
|             |         "KeystoneCredential1": "pGZ4OlCzOzgaK2bEHaD1xKllRdbpDNowQJGzJHo6ETU=",    |
|             |         "CephClientKey": "AQDloEFYAAAAABAAoTR3S00DaBpfz4cyREe22w==",              |
|             |         "NovaPassword": "wD4PUT4Y4VcuZsMJTxYsBTpBX",                              |
|             |         "AdminToken": "hdF3kfs6ZaCYPUwrTzRWtwD3W",                                |
|             |         "RedisPassword": "2bxUvNZ3tsRfMyFmTj7PTUqQE",                             |
|             |         "MistralPassword": "mae3HcEQdQm6Myq3tZKxderTN",                           |
|             |         "SwiftHashSuffix": "JpWh8YsQcJvmuawmxph9PkUxr",                           |
|             |         "AodhPassword": "NFkBckXgdxfCMPxzeGDRFf7vW",                              |
|             |         "CephClusterFSID": "3120b7cc-b8ac-11e6-b775-fa163e0ee4f4",                |
|             |         "CephMonKey": "AQDloEFYAAAAABAABztgp5YwAxLQHkpKXnNDmw==",                 |
|             |         "SwiftPassword": "3bPB4yfZZRGCZqdwkTU9wHFym",                             |
|             |         "CeilometerMeteringSecret": "tjyywuf7xj7TM7W44mQprmaC9",                  |
|             |         "NeutronMetadataProxySharedSecret": "z7mb6UBEHNk8tJDEN96y6Acr3",          |
|             |         "BarbicanPassword": "6eQm4fwqVybCecPbxavE7bTDF",                          |
|             |         "SaharaPassword": "qx3saVNTmAJXwJwBH8n3w8M4p"                             |
|             |     },                                                                            |
|             |     "parameter_defaults": {                                                       |
|             |         "OvercloudControlFlavor": "control",                                      |
|             |         "ComputeCount": "2",                                                      |
|             |         "ControllerCount": "3",                                                   |
|             |         "OvercloudComputeFlavor": "compute",                                      |
|             |         "NtpServer": ""                                  |
|             |     },                                                                            |
|             |     "environments": [                                                             |
|             |         {                                                                         |
|             |             "path": "overcloud-resource-registry-puppet.yaml"                     |
|             |         },                                                                        |
|             |         {                                                                         |
|             |             "path": "environments/inject-trust-anchor.yaml"                       |
|             |         },                                                                        |
|             |         {                                                                         |
|             |             "path": "environments/tls-endpoints-public-ip.yaml"                   |
|             |         },                                                                        |
|             |         {                                                                         |
|             |             "path": "environments/enable-tls.yaml"                                |
|             |         }                                                                         |
|             |     ],                                                                            |
|             |     "template": "overcloud.yaml"                                                  |
|             | }                                                                                 |
| Scope       | private                                                                           |
| Created at  | 2016-12-02 16:27:11                                                               |
| Updated at  | 2016-12-06 21:25:35                                                               |

Note: 'environment' is an overloaded word in the TripleO world, be careful. Heat environment, Mistral environment, specific templates (e.g. TLS/SSL, Storage...), your whole setup, ...

Bonus track

There is documentation on going from zero (no plan, no nodes registered) till running a deployment, directly using Mistral:

Also, with the way we work with Mistral and Zaqar, you can switch between the UI and CLI, or even using Mistral directly, at any point in the process.


Thanks to Dougal for his feedback on the initial outline!

Leave a comment

EFI, Linux and other boot-loading fun a.k.a. where's my Grub gone

I've been gaming more recently, on hardware that is decent-in-some-contexts-but-definitely-not-in-this-one which has meant pathetic frame rates as low as 7~12FPS as my save files grew bigger. A kind soul took pity on me and installed a better graphics card in my machine while I wasn't looking - which of course is when everything started going wrong.

I'll gloss over the "Not turning on" part because that was due to mislabelled wires - the real problem began when Windows for some reason picked up that something had changed at boot time, and promptly overwrote the boot loader.

Cannot boot from USB keys

None of my LiveUSB sticks would boot.

This turned out to be due to the device (or the system on it?) not being compatible with EFI. I'm not sure how to make a EFI-compatible Live USB system and didn't need to in the end - if you absolutely need to, enabling CSM mode in the BIOS ("Compatibility Support Module") was useful there, but likely wouldn't have helped with fixing my boot-loader. EFI and Legacy OS shouldn't be dual-booted in parallel - you can read more about this at the beginning of that excellent page.

Side-note: "chroot: cannot execute /bin/sh"

That was because the Live USB stick turned out to be a 32 bit system, while my desktop OS is 64 bits.

Where's my EFI partition anyway

I found an old install CD for Debian testing 7.10 (64 bits) lying around that turned out to have a Rescue mode option.

To prepare the system for the chroot that would fix All My Problems, first I had to figure out what was on which partition. The rescue mode let me mount them one by one and take a peek, though using parted would have been much faster.

# parted /dev/sda print
Model: Blah
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  420MB   419MB   ntfs            Basic data partition          hidden, diag
 2      420MB   735MB   315MB   fat32           EFI system partition          boot, esp
 3      735MB   869MB   134MB                   Microsoft reserved partition  msftres
 4      869MB   247GB   247GB   ntfs            Basic data partition          msftdata
 6      247GB   347GB   100GB   ext4            debian-root                   msftdata
etc etc etc

So my Debian partition is on /dev/sda6, the EFI stuff is on /dev/sda2. I need to make a Debian chroot and reinstall Grub from there - that's the kind of stuff I learnt last time I broke a lot of things.

Let's chroot and grub!

After selecting the "Execute a shell in Installer environment" option:

# mount /dev/sda6 /mnt
# mount -o bind /dev /mnt/dev
# chroot /mnt

Error: update-grub: device node not found

This one I think happened because I only bind mounted /dev, when you also need things like /dev/pts, /sys, /proc.

# for i in /dev /dev/pts /proc /sys ; do mount -o bind $i /mnt$i ; done

Error: grub-install /dev/sda: cannot find EFI directory

That one was before I figured out I also needed to mount the EFI special boot partition - sda2 as shown in the printed output.

# mount /dev/sda2 /mnt/boot/efi

From then on I read about the efibootmgr tool and decided to try and use that instead.

Error: efibootmgr: EFI variables are not supported on this system

Outside the chroot, you need to load the efivars module:

# modprobe efivars

How are things looking by now

# modprobe efivars
# mount /dev/sda6 /mnt
# mount /dev/sda2 /mnt/boot/efi
# for i in /dev /dev/pts /proc /sys ; do mount -o bind $i /mnt$i ; done
# chroot /mnt

Usually I can never remember the mount syntax (does the mount point come first or second?!) but I typed these commands so many times today, I bet I'll remember the syntax for at least a week.

Playing with efibootmgr

I tried to use the following command from the "Managing EFI Boot Loaders for Linux" page but it didn't quite work for me.

# efibootmgr -c -d /dev/sda -p 2 -l \\EFI\\debian\\grubx64.efi -L Linux

While this did add a Linux entry to my F12 BIOS boot menu (yay!), that booted straight into a black screen ("Reboot and Select proper Boot Device or Insert Boot Media" etc etc). Later on I learnt about the efibootmgr --verbose command which shows the difference between the working entry and the non-working one:

# efibootmgr --verbose
Boot0000* debian    HD(2,c8800,96000,0123456789-abcd-1234)File(\EFI\debian\grubx64.efi)
Boot0005  Linux    HD(2,c8800,96000,0123456789-abcd-1234)File(\EFI\redhat\grub.efi)\EFI\debian\grubx64.efi

I'm not quite sure how the path ended up looking like that. It could be a default somewhere, or I'm quite willing to believe I did something wrong - I also made a mistake on the partition number when I first ran the command.

But how did you fix it?!

Despite showing all the options I wanted in the efibootmgr output within the chroot, running grub-install and update-grub multiple times did nothing: I'd still boot straight into Windows or straight into a black screen. The strange thing is that even though only "Windows Boot Manager" and my new "Linux" entry were in the F12 boot menu, the BIOS setup did offer a 'debian' entry (created automatically at install time a long time ago) was in the boot ordering options. Moving it around didn't change a thing though.

The efibootmgr man page talks of a "BootNext" option. With the 'debian' entry right in front of me, why not try it? It's entry Boot0000 on my list, therefore:

# efibootmgr -n 0

Ta-dah! I rebooted straight into Grub then Debian. From there, grub-install /dev/sda and update-grub worked just fine.

Things I still don't know

  • Why did this happen in the first place? Can I prevent it from happening again?
  • I'm not sure why the grub install properly worked that last time. Did I miss something when working from the chroot?
  • Where does the "redhat\grub.efi" line come from, and can I amend that?
  • Why does Windows take so long to restart each time, when I don't even log in?


  • Linux on UEFI: A quick installation guide - I found this site incredibly informational.
  • The efibootmgr man page is very nice and contains useful examples.
  • GrubEFIReinstall - I probably would have tried that tool at some point. I postponed because I didn't have an easy way to burn a CD and wasn't sure about how to boot from USB without enabling CSM.
  • Booting with EFI, a blog entry about fallback boot loaders. While this didn't help in my case, I found the article very clear and enjoyed getting an explanation of the context around the problem in addition to the solution.

Punch line: the graphics card wasn't the bottle neck and my frame rate still hovers around 9FPS.

Leave a comment | 4 so far

Switching locale (Gnome 3, Fedora 20) and making sure all the menus switch too

In the spirit of immersion, I switched the laptop's language to Japanese, however most of the Gnome menus remained in English even after switching the System Language altogether, logging out etc. Another profile on the laptop shows the menus for Activities, etc in Japanese just fine so it wasn't a missing package. I found the following in ~/.profile, which seems a bit heavy-handed but does do the trick. For future reference:


Note on restarting X one is asked if they want to change the names for the default folders like Documents, etc. Personally I find it makes using the CLI a pain and don't recommend it.

Leave a comment



Last week-end I attended FOSDEM for the 7th time. It's kinda strange to say and think - if someone tells me they've been going to this or that open-source conference for 7 years I tend to assume they're hardcore and totally know what they're doing. I go to hang out with cool folks and learn new things. This year's FOSDEM didn't disappoint in that regard!

As usual, the conference was packed and most rooms filled up quickly, but I was happily surprised to see it was still possible to squeeze in some of the more popular rooms regardless. I think many devrooms organisers are well aware of the frustration with not being able to get in and they did a great job at encouraging/demanding folks use all seats rather than leave spaces in the middle, which really helped (special kudos to the Legal devroom, which was in a smaller room in H). Also the main conference organisers appear quite good at trying to adjust the room size based on popularity year to year (e.g. the Mozilla room used to be utterly impossible to get into).

Some of the conference highlights from my perspective:

Identity Crisis: Are we who we say we are?

This was the first keynote on Saturday morning, which I think did a good job of bringing up many possible ambiguities hidden in the "we" we use when contributing to a project. One of the strengths of open-source is that we're quick to say "we" and include everyone, but sometimes it bears more thinking or clarification of who we actually mean with "we" - sometimes two "we" can describe different subgroups of contributors even in the same sentence. Taking the time to think explicitly about who we mean, and avoid unintended conflicts of interests is important.


Fog of War - The GNOME Trademark Battle

The story of what was happening in the background during the Gnome battle for their trademark with Groupon last year, told by a Gnome board member and the lawyer that helped them on the case. Interesting insights thanks to the lawyer's perspective particularly, who also took a guess at what possibly happened in the Groupon lawyers' mind during their risk analysis and the consequences (e.g. "Groupon was dealing with an animal they'd never seen before." A charitable org not willing to be silenced or take a big donation.) Not a kind reflection on Groupon.


Why Samba moved to GPLv3: Why we moved, what we gained, what we lost.

Emboldened by having managed to get a seat in the Legal devroom, I decided to also stick around for the next talk. I hadn't attended a talk on GPLv3 in a few years and I wasn't to be disappointed. It was a very honest and funny talk - I knew of Jeremy Allison aka the Samba guy, but I didn't know he was such an entertaining speaker. Overall Samba seems very happy with the move to GPLv3, it simplified a lot of things for them especially in terms of copyright managenent (some companies are just nasty), and most of the contributors and users they initially lost ended up returning (multiple closed-source vendors being bought out and leaving their customers in the cold likely helped). They felt really let down that the FSF didn't force their own projects to move as well (though I understand that is not the case anymore) and of course the Linux kernel being GPLv2-only is hurtful too. The speaker is convinced that all the scary stuff around GPLv3 is FUD and everyone should switch to using GPLv3+ right now if they don't have to link to v2 stuff. An audience member did raise an issue/unclear point with the v3 licence, for when a company rents a device to a customer (that the user doesn't actually own and thus perhaps? shouldn't be allowed to modify).


Participation metrics at Mozilla: A story of systems and data

For projects that depend so heavily on volunteer contributions as Mozilla does, understanding who the community is made of and where/when people are being lost or leave is really important. The speaker started by showing us some of the ways they tried and failed to measure participation and what they ended up with. They defined what "participation" means by formalising paths a contributor might take across their systems (e.g. file a bug, comment on a bug, translate a string, etc) and they extract and map the data they have to these paths. This enables them to also deduplicate contributor information: for instance it's not because you have 100 translators and 300 developers that you have 400 contributors, people can do more than one thing, and it also lets them identify more clearly whether someone is leaving the project altogether or simply moving to another area. Very interesting stuff!

This is work in progress but their current results and reports are available at Are we a million yet.


Maintaining & growing a technical community: Mozilla Developer Network

The other Mozilla talk I attended explored the meaning of community and the motivations behind why people start contributing, why they continue to contribute and how to help folks feel involved and want to contribute. The speaker made some really good points, one that really stuck with me being that contributors ≠ community. It's really important to connect contributors to your community or they will not stick around! The example she used was getting people to contribute at hackathons-like events, but then disappear - as someone who's run such events that certainly rang true, simply showing folks they can make a positive impact easily is not enough to make them come back or feel part of the community.


Retooling Fedora: A Retrospective on Fedora 21 (and looking to 22)

I knew Fedora had been changing their model since the past release but I hadn't been following closely. This clarified the goals and the why, and I was very impressed with the beginning of the talk where the speaker (Matthew Miller, the current Fedora Project Leader) took a really hard look at where distributions are today and why they appear to be becoming less relevant - for instance looking at the contrast between the number of open-source projects available on platforms like Github compared to what is actually packaged in the distro. People used to care about getting their software into the major distributions but it doesn't seem to matter as much nowadays. In that light the "ring" graph showed toward the end, explaining that perhaps the apps at the outer layer don't need as strict and stringent criterias for inclusion than the more core OS components, totally makes sense and the future looks interesting.



I continue to be hugely impressed by how much Mozilla cares about improving the experience for new and existing contributors (impressed but not surprised! Their "Get Involved" page remains excellent, letting you get in touch with real people while showing at one glance all the different ways you can help, and having a mentored bugs process for new contributors is an awesome step-up from simply tagging easy bugs. Keep rocking and showing us all how it's done Mozilla!)

Videos of the talks should be available in time on the FOSDEM website.

Leave a comment

Training at EuroPython 2014 Making your first contribution to OpenStack

OpenStack logo

Last week I ran a 3-hour training on how to get started contributing to OpenStack at EuroPython. The aim was to give a high-level overview of how the contribution process works in the project and guide people through making their first contribution, from account creation to submitting a patch.


The session starts with an extremely fast overview of OpenStack, geared toward giving the participants an idea of the different components and possible areas for contribution. We then go through creating the accounts, why they're all needed, and how to work with DevStack for the people who have installed it. From there we finally start talking about the contribution process itself, some general points on open-source and OpenStack culture then go through a number of ideas for small tasks suitable for a first contribution. After that it's down to the participants to work on something and prepare a patch. Some people chose to file and triage/confirm bugs. The last part is about making sure the patch matches the community standards, submitting it, and talking about what happens next both to the patch and to the participant as a new member of the community.


During the weeks preceding the event, I ran two pilot workshops with small groups (less than 10 people) in my local hackerspace, in preparation for the big one in Berlin. That was absolutely invaluable in terms of making the material more understandable and refining the content for items I didn't think of covering initially (e.g. screen, openrc files) and topics that could use more in-depth explanations (e.g. how to find your first task), timings, and generally getting a feel for what's reasonably achievable within a 3-hour intro workshop.


I think it went well, despite some issues at the beginning due to lack of Internet connectivity (always a problem during hands-on workshops!). About 70 people had signed up to attend (a.k.a. about 7 times too many), thankfully other members of the OpenStack community stepped up and offered their help as mentors - thanks again everyone! In the end, about half the participants showed up in the morning, and we lost another dozen to the Internet woes. The people who stayed were mostly enthusiastic and seemed happy with the experience. According to the session etherpad, at least 5 new contributors uploaded a first patch :) Three are merged so far.

Distributing the slides early proved popular and useful. For an interactive workshop with lots of links and references it's really helpful for people to go back on something they missed or want to check again.


The start of the workshop is a bit lecture-heavy and could be titled "Things I Desperately Wish I Knew When Starting Out," and although there's some quizzes/discussions/demoing I'd love to make it more interactive in the future.

The information requested in order to join the Foundation tends to surprise people, I think because people come at it from the perspective of "I want to submit a patch" rather than "I am preparing to join a Foundation." At the hackerspace sessions in particular (maybe because it was easier to have candid discussions in such a small group), people weren't impressed with being forced to state an affiliation. The lack of obvious answer for volunteers gave the impression that the project cares more about contributions from companies. "Tog" might make an appearance in the company stats in the future :-)

On the sign-up form, the "Statement of Interest" is intimidating and confusing for some people (I certainly remember being uncertain over mine and what was appropriate, back when I was new and joining the Foundation was optional!). I worked around this after the initial session by offering suggestions/tips for both these fields, and spoke a bit more about their purpose.

A few people suggested I simply tell people to sign up for all these accounts in advance so there's more time during the workshop to work on the contribution itself. It's an option, though a number of people still hit non-obvious issues with Gerrit that are difficult to debug (some we opened bugs for, others we added to the etherpad). During one of the pilot sessions at the hackerspace, 6 of the 7 participants had errors when running git review -s  - I'm still not sure why, as it Worked On My Machine (tm) just fine at the same time.

Overall, I'm glad I did this! It was interesting to extract all this information from my brain, wiki pages and docs and attempt to make it as consumable as possible. It's really exciting when people come back later to say they've made a contribution and that the session helped to make the process less scary and more comprehensible. Thanks to all the participants who took the time to offer feedback as well! I hope I can continue to improve on this.

Leave a comment

Testing in Horizon Unit testing for the Openstack Dashboard

Belatedly, here are the notes for the design session/tutorial I gave about testing in Horizon at the OpenStack Summit in Portland, back in April. The etherpad is available over there. Session description:

The main aspect: the Horizon unit tests can be quite complex for new contributors and people extending Horizon to wrap their head around. Mocking with mox, the django unit testing framework,the openstack specific parts of the testing framework, selenium, fixtures/test data handling, qunit...This session could work as a tutorial/tips and tricks on the different testing components. Common errors being thrown and how to debug them. If people could bring up their pain points, that would also be useful.

If there is time, it would be interesting to also address the issue from another angle and think on how to improve what we have, particularly on the Selenium front which has been quite unstable.

General structure

There are 3 main parts to Horizon testing (4 if you include the bits that come from the Python unit testing framework, but we won't get into it here. If you've done unit testing before, it's the usual set of assertions and scaffolding that come with any unit testing framework).

As an example to map to what this is all talking about, I recommend keeping InstancesTest.test_index in the background.

Django unit testing


At the moment Horizon is compatible with 1.4 onwards. The django documentation is excellent and I recommend having a look. Thanks to django we get a lot of goodies for free to help with testing a web application. Among other things:

  • A test client, which mimics a very simple browser (no Javascript) to do GET and POST requests, and built-in tooling to have interesting interactions with the responses.
  • A bunch of additional assertions, to check the HTML, templates, etc., all documented in the link above.

If you're familiar with django already, or while you're reading the django docs, there are a couple of things to watch out for:

  • Horizon does not use, and does not have a database
  • Horizon doesn't use fixtures either (actually it does, but they're very different since they're not done the django way - cf. no models)

Horizon unit testing


Helper classes:

There are some docs for testing in Horizon, which contain useful advice for writing good tests in general. A few sections only are specific to Horizon:

Now let's have a look at, where the TestCase classes we extend in Horizon tests are defined.

The setUp() and tearDown() methods do the housekeeping for mox/mocking so that we don't have to worry about it when writing tests. The aforementioned Horizon-specific assertions are also defined in this class. It extends the django TestCase class thus all of the django unit test goodness is available.

In general, this class is the best documentation available of what happens in the tests and how they are set up.

Openstack Dashboard unit testing


Test data:

Helper classes:

The Horizon tips and tricks mentioned earlier also apply, but there are no specific documentation page about the topic.

A quick overview of openstack_dashboard/ and the sections that matter to us in the context of unit testing:

  • APIs

The API directory is the only place that talks directly with the outside world, that is, the various openstack clients. This is why Horizon doesn't have a database, because it doesn't store any data itself.

  • Test Data

The test data is also stored in a single directory, and contains the fixtures, that are used to represent (mock) the data returned by the different clients.

  • Helper classes

Like in the "framework" part of Horizon, a file defines the TestCases we extend later in the unit tests. This is where a lot of the magic happens: the TestCase extends the Horizon TestCase helper class described earlier, loads the test data, sets up mox, creates a fake user to log in. There's also a couple of useful assertions defined that are used all over the place.

There are other TestCase classes in there, for tests that may require an Admin user, testing the APIs, or Selenium.

A quick look at the example

The flavours returned by self.flavors.list() come from the test data.

We'll look at the mocking stuff in the Tools section. The APIs being mocked all live in the API directory, so this is the only place that needs to be mocked.

self.client() is the default django client, reverse() and assertTemplateUsed() also come from django.

self.assertItemsEquals() is a Python assertion.



In Horizon, mocks are used a lot, everywhere or otherwise running the unit tests would require a fully set up, running Openstack environment.

I found mox a bit difficult to get used to. There's a specific terminology, that translates to a different set of steps than is common in other mocking tools like mock.

First you record. That's the part in the tests where you create the stubs (in a decorator in the example) and "record" what you expect will happen (that's the place in the example that says: "when api.nova.flavour_list() is called with these exact arguments as described, return self.flavors.list()").

Then you replay, with self.mox.ReplayAll() which will make sure the rest of the test will get the data it expects, that you just mocked.

Finally, the reverify step is done in the parent TestCase class' tearDown() function, which calls self.mox.VerifyAll() and ensures the functions recorded were all called, and in the order defined.

There are lots of catches in mox, it's quite strict. Order matters. By default it assumes the mocked function will only be called once and fails otherwise (that's a big one that can be difficult to track down). MultipleTimes() will save you if a function needs to be called more than a couple of times.

Stubbing can be done via a decorator (which is the favoured way going forward) or a StubOutWithMox function, which can still be found in places.

Mox errors can be confusing and I recommend reading the Horizon docs about understanding mox output, which have a couple of paragraphs explaining different errors that may be encountered, the dreaded Expected and Unexpected calls.


Helper classes:

We use Selenium for testing Javascript interactions. It's a bit heavyweight since it requires starting a browser, so Python unit tests are preferred when possible.

It's more stable now (thanks Kieran), so hopefully we can write a few more tests for the places where it's needed.

qUnit (briefly)

qUnit is used for some of the pure Javascript tests.

It's not used a lot in Horizon. The handmade fixtures take a lot of effort to make so maybe it's better to use Selenium in most cases.

Tips and tricks

  • See the Tips and tricks from the Horizon testing topic
  • Use pdb to check the environment status
  • Anything else? From the session:
    • Mock everything, and if it doesn't work mock it again.
    • Selenium tests: having a flag to turn off/on mocking? So we can run them as integration tests when needed and make sure we still match the correct APIs - cf. blueprint
    • Using Selenium tests as integration tests: build more tests (start a VM, ssh into it)


Unfortunately, the day was running late (and I was speaking at the very next session) therefore the discussion part didn't have time to happen.

I'm disappointed about that and would welcome people discussing their experience and pain points, particular from a newcomer's perspective.

Fortunately when it comes to discussing the Selenium issues, Kieran Spear had successfully fixed it right before the Summit :)

Leave a comment | 1 so far

Evolving Open-Source Night Open-Source Night - June

The monthly Open-Source night experiment continues. On Wednesday, June 19th we had the June edition of Open-Source Night. Rory gave us a slightly-longer-than-15-minutes talk on OpenStreetMap, and the kind of contributions the project welcomes (data data data, really!). I was the only one to volunteer for a lightning talk, in stark contrast with the last event where we had multiple ones both by people attending open-source night and network people who happened to be visiting the hackerspace at the time.

Rather than doing an on-topic talk about an open-source project, I did a meta-talk about Open-Source Night itself and different ways in which it could evolve.

I make no secret that I don't think open-source night works very well in its current format. My goal (and measure for success) is to help people actually get started contributing.

Note: if you were at my deep dive on contributing to open-source and planning on attending the next open-source night, please do come!! This all just means that I think there are things that can be improved :)

Reminder: The current format

We're currently meeting on the 3rd Wednesday of the month. The event usually starts with two 15 minutes talk, ideally one on the life of open-source (e.g. licences, version control, IRC, using the command-line...) and one on how to contribute to a specific project. Then there's a number of 5-minutes-long-or-less lightning talks where people can introduce the project they will be working on during the evening. Then people break into groups or independently work on an open-source project of their choice.

Or that's the idea anyway. The talks usually work well and are inspiring, though they tend to run overtime and then people have trouble sitting at a table and doing things.

The future

These are my thoughts and ideas as to where open-source night might go in the future. These are not plans. I would like to hear feedback from interested people - attendees, would-be attendees, other organisers and thoughtful passerbys.

Topics: General open-source vs Project-specific

I see value in both topics, but perhaps attendees and would-be attendees favour one or the other, both, or neither? I haven't really heard much on this, what people find most useful. I think the project specific talks at least are interesting for both newcomers and established contributors, to see how other projects do things.

I believe 15 minutes is a good amount of time to get an overview, get inspired and get ideas. And not get too bored if already familiar with the topic.

I could see the value and how efficient it would be to focus on one project for a full session and guide people through contributing to it. However I can also see how it could be offputting to people not particularly interested in the project (e.g. "I don't use that distro, why should I bother attending?"). Perhaps as separate, off-shoot events if people are interested in leading that kind of session (get in touch!).

Topics: All kind of contributions vs Focusing on code

At the moment, I try really hard to emphasise (and encourage speakers to do the same) all the kinds of contributions that can be made - and are well needed! - even though my own experience lies in code-based contributions. Maybe I should give up on being inclusive and focus on what I know best, rather than try to be all things to all people? Code-focused open-source events could go from learning to program to fixing a bug.

Initially I was hoping people would step up to talk and encourage people to join their area of interest (I think we have e.g. experienced open-source translators around...) but that hasn't happened.

This is actually a point where someone came up to me after the talk and said straight off they really liked the breadth of contributions demoed during the talks, in particular mentioning last month's talk by Guilherme on OpenMandriva that did a great job showing how someone can help, in a multitude of ways, even if they're not all that confident in their coding skills.

Format: More course-like?

A couple of days before the June OSS Night I was pointed to this article on a really, really interesting summer course on learning to program the open-source way. That's a really cool concept. Should we entertain the thought of doing something similar during open-source night? e.g. A session on learning how to use version control with exercises, very workshop like, one month, some other topic the next one, etc.?

Probably not, but something to consider as a separate course with a shorter timeline. A course with one session a month will lose people and have little momentum. Is this the kind of things people have an interest in learning?

Format: Doing vs Listening/Talking

My goal with this event is still to get people started contributing. I'm not interested in organising a monthly night of talks. Finding speakers is stressful. If the talks aren't followed by some contributing action, to me the event is failing and I'm not interested in continuing to organise it. There are plenty of events around Dublin already where people can meet, talk tech and shoot the breeze.

With regard to open-source related talks, I think that's already handled well by the ILUG folks, who are now keen to set them up regularly again under the new chairmanship :) And we can join forces if that's the most attractive part of the event to folks. If your main interest is in having a regular night of open-source talks, get in touch and I'll be happy to help you have this in Tog. I'd attend with pleasure anyway, I'm just not interested in organising it and go speaker-hunting every 3 weeks.

I still believe we can make something really cool happen by putting in the same room people experienced in open-source together with newcomers interested in contributing. So I'm not giving up yet!

There's of course also the timeframe issue: with or without talks, an evening of maybe 3 hours is not a lot of time to accomplish something. Maybe we could (also/instead?) have events on Saturdays? And/or week-end workshops, Friday eve to Sunday?

HOWEVER, in any case an evening is still enough time to accomplish something, get started, get the momentum going, get unblocked and finish your contribution later at the week-end, in your own time.

You: Why are you here anyway*? ;)

* Or why weren't you? :) I'm just as interested in the answer to that!

Are you interested in learning how to contribute? Interested in helping and mentoring newcomers? What were you hoping this evening would be about?

I then invited people to have a productive discussion with me about this should they wish to, somewhat contradicting my own doing vs talking rant :-)

Please feel free and welcome to continue the discussion in the comments or by email, I would love to pick more brains and exchange ideas about this.

Django challenge

To avoid the talk being entirely meta (and in case people didn't care that much about all the blah blah blah and more about the doing!), I issued a challenge to attendees as well: this evening, run the Django unit tests suite. If that's something you're set up for, it'll take 2 minutes. If you're familiar with the concept but don't have all the dependencies set up yet it'll take 20 minutes. If this is all new to you it might take 2 hours, but what you learn you'll be able to reuse when you start working on a project you care about in the future, and it means it'll take less long then.

One person took me up on it and it took them 10 minutes. This shows how possible it is to actually get the ball rolling during open-source night, get people to realise they're not that far away from a first contribution.

I feel I should give the disclaimer that since the last time I talked about how to contribute to Django, the Django folks added to their docs a tutorial on how to make your first contribution, which just makes the project that little bit more awesome (and this challenge, easier to solve!)

Next Open-Source Night: July

So next month. That'll be on the 17th of July. Are you interested in giving a talk? :)

If no one volunteers we'll have a session similar to the first event except with more lightning talks. Lightning talks don't have to be prepared, there's no need for slides or anything you don't fancy. It's as simple as chatting about what you plan on doing or would like to do during the evening, inviting others to join you if they'd like.

It can be like:

"Hello, I'm Chris, a contributor to AwesomeProject which is a project that does this and that and also that thing. At the moment we're looking for help in $area1, $area2, $area41, if you think that's cool and you'd like to help, I'll be sitting at that table over here, come and chat with me. Maybe I can help you find a good first task. Otherwise I'll be working on the defroglirnator for the project -- er if you have any experience in that area I'd love to chat to you too."

or maybe

"Hey, I'm J. Bloggs, I've been using Wordpress for a few years, I think it's an awesome project and I'd like to start giving back. Tonight my plan is to figure out the new contributor process - if you're interested too, we can do this together. Come and chat with me."

It doesn't matter if there is no existing contributor to the specific project in the room. Since there are people familiar with the way open-source projects and communities usually tick, they will be able to help you if you get stuck.

Ok, that's it! I'm hoping to also have the time to find a few good first tasks in a new project, maybe LibreOffice. If not, then we can figure it out together on the day :)

I'm very much looking forward to hearing your thoughts, suggestions and ideas about all this, and perhaps also see you on the 17th.

Leave a comment | 2 so far

Open-Source Night #2: March 2013

On Wednesday the 20th, we had the 2nd edition of Open-Source Night in Tog. I think it went well. Once again there was about a dozen attendees, many of whom have never contributed to open-source before. A third of them were also in Tog for the first time. It might be too early to matter but there was also very little overlap with the audience from last time.


We started the evening with 2 talks, meant to be about 15 minutes long each. Mark started the evening telling us about open-source licences and the philosophy they encapsulate/were born from. Then I walked through how one would go about contributing to Django, basically clicking through the Django website and explaining different tasks the project needs help with, particularly for bug fixing contributions.

After this, we had 2 lightning talks that were meant to last 2 to 5 minutes, to give people a chance to talk about a project they contribute to and get people to join in. This time the talks were more about ideas, which is fine, but both also ran overtime, which is less cool. I'm not sure if either found additional contributors/would-be contributors out of it for the evening.


The second part of the evening, the part that should be hands-on, didn't go so well. After the talks (which lasted for 1h30 instead of 45mins) and a tour of the hackerspace for the new people, most continued chatting instead of sitting down and getting things done. This especially saddened me for the ones who had never contributed before. The goal of the event is to help newcomers get started contributing, when they have experienced people at hand to ask questions to.

Next time

I'm not sure how to improve this next time and help attendees get started actually doing stuff. Running overtime for the talks really hurt for the rest of the evening, which is already such a short time to accomplish something. An idea: after my talk I was asked "How long would it take for someone to start from nothing to being able to run the Django unit test suite?" and maybe this kind of well-defined, self-contained task would be good to help people get started. It's not a contribution yet, but it's a first, necessary step toward it (for code contributions in any case), and it could be fun to try and mix this with some sort of open badge.

Somewhat related announcement: open-source night won't happen on April 17th next month but probably on April 24th instead. Check the calendar for confirmation. If you're interested in speaking on a topic relating to the life of open-source or a project in particular, please get in touch :)

Leave a comment

Open-Source Night: Event #1 February 20th

On Wednesday, Tog hosted the first monthly Open-Source Night.

It's an event I'd been wanting to organise for a while, with an eye on it being hands-on and slanted toward helping interested people get started in open-source, but I wasn't sure what format would work best. I'm still not sure, but in the spirit of release early, release often, I thought I'd give it a shot for a few months and iterate.

For the first event, about a dozen people showed up. About 7-9 of them had already made some kind of contribution, most people had a clear idea of the project they wanted to contribute to for the evening, and 3 were hesitant and not sure what they wanted to do.

Blackboard with project names

We started with 2 super short talks, an ill-prepared one from myself about what to do tonight: basically find the contributor's guidelines for the project you're interested in and speak to the person next to you for help, since we had such a skewed ratio of experienced contributors. Triona followed with a talk on what she planned to do in the evening with Free Penguin, an open-source sewing pattern for Tux plushes. The maintainer hasn't updated nor responded to emails in years, so it seems it will need to be forked in order to start improving the documentation. Open-source projects aren't all about code! :)

I directed the hesitant project-less people toward Cheryl and the Dreamwidth project, which has an excellent reputation for being friendly to newcomers. Even without an experienced contributor around, I thought figuring things out together would be a fun learning experience. It may not have been that effective though, people were interested and looked around but nothing got accomplished (perhaps that is to be expected for a first couple of hours getting acquainted with a project and open-source?). Then further efforts were thwarted by technical problems (bugzilla down). Cheryl's thoughts abut this is that it's difficult to get into a project one doesn't feel strongly about (a similar downside applies to projects discovered via OpenHatch, as someone else mentioned to me).

There were a couple of serendipitous meetings, like the person wanting to get started with Debian packaging who happened to be sitting besides a Debian Developer.

But overall, I think having encouraged people to come along already having a project in mind made it difficult to form groups and encourage collaboration, because people ended up working on the project they had planned to alone. It may not have been a great experience, particularly for people who didn't know anyone or hadn't been in Tog before.

I also need to become more familiar with projects who have good, specific non-programming-related tasks for newcomers. I had a general idea but wasted time trying to find the details. We had a graphic designer interested in either contributing his design skills, translating or participating in testing efforts but I wasn't able to quickly find a good "Here's a concrete task you can do now" for some of the better known projects. He did discover InkScape and became eager to learn it, so I hope to see him again in Tog in a few weeks for teaching an intro workshop to InkScape :-) (Thanks Borud!!)

Ideas on how to evolve the format for next time:

Choose one project and make it the main focus of the evening, at least at the start. Meaning only one presentation, that is a bit longer (ideally 20 minutes, max 30 -- we still need time to actually do stuff!) and give specific, step-by-step instructions on "this is where you go to find something to work on, this is how you choose a task" and afterwards have the people interested in working on the project do so together - several people to one task can work, to encourage learning together and avoid getting stuck. People are still welcome to work on whatever else they want to of course. This was suggested by Ulrich based on the recent Debian Bug Squashing Parties he attended.

Becky said there was an interest in a GitHub pair programming type of exercise. People upload code on GitHub they never touch again. Working on someone else's code with the help of the author could turn into an instructive experience. It would also be cool to see what a pull request looks like from both sides.

I think we can try both these things for next time, the GitHub pair programming could start after the presentation for people not interested in working on the highlighted project.

Now. The next step is to find a project to highlight and a willing contributor who'd like to present and guide, for the next session on March 20th. Ideas, volunteers? :)

Feedback and general thoughts on evolving the format are warmly welcome as well.

Leave a comment

Interested in open-source? Come to Tog!

Are you an experienced open-source contributor interested in recruiting new people for your project?

Are you a fan of open-source who would be interested in contributing at any level but isn't sure how to?

Come to Tog's first Open-Source Night on February 20th!

These hands-on sessions aim to bring together experienced open-source contributors with people who would like to get started but aren’t sure where to start or would generally benefit from having someone to ask questions to.
Every month we will start with a couple of people speaking for 5-10 minutes, to introduce the project they are working on, what is the usual path for contributing and where they are currently looking for help. Then we will form groups and work on making a contribution for the rest of the evening.

I'm hoping to make this into a regular monthly event. The current plan is to try it for a few months and see what it becomes. This will heavily depends on who attends so, help me recruit lots of interested people from both side of the contributor spectrum in Dublin :)

Leave a comment

Friendliness in open-source

The general view of open-source communities when standing at the edges is probably a vision of endless flames, strong personalities clashing, patches being ripped to shreds on mailing-lists, RTFMs, and the general need to have a thick skin when going in there or being crushed to pieces. The high-profile projects where one might think to contribute first like the Linux Kernel can have quite an intimidating culture, keeping lurkers looking out from stepping in.

I rarely read stories about the really friendly projects that do their best to mentor newcomers.

I'm currently mentoring for the OpenStack project as part of the Gnome Outreach Program for Women. Everyone I see talking to the interns, whether or not they're directly involved with or even aware of OPW, is helpful and makes the time to be friendly and answer questions ; what they see is new contributors interested in helping out and it's in their own interest and the project's to give a hand at the start, when it is most needed.

If you like open-source and sometimes think you'd like to contribute if you could: explore the community for the project(s) you're interested in. Most of them are really nice places to be. Have a look. Ask someone on IRC or on a mailing list for where to find directions on how to get started. Healthy communities are concerned about being welcoming and attracting new blood, because they know they need it to survive and be sustainable.

And if you're still hesitant about jumping in and have a specific question I might be able to help with, get in touch :)

Leave a comment

Playing from emacs

I enjoy listening to and recently decided it would be handier to control it from within my emacs session. Getting it to work didn't take too long but wasn't as straightforward as I hoped, mostly because it's easier to find documentation for older versions of emms (including on the official website) and the parts have been entirely rewritten recently. Anyhow! If you're in a rush, the short version is: find the latest version of the code and follow the documentation from the source itself!

What to install

From your package manager, using Debian here:

aptitude install emms mplayer2

Note, that installing mplayer instead worked fine on an Ubuntu machine.

Getting an API key

Search the documentation linked above to get more details. Basically, using the latest version of the API requires a secret API key, which isn't a concept that works well with GPL software. To work around this, we request a personal API key, which we will add to our .emacs config file.

Request a key at The keys will be displayed on screen rather than sent to you, therefore write them down now. As far as I can tell the "app description" will only be seen by yourself, when you allow emms-lastfm-client to access your account so don't worry too much about the description.


Add the following to your config file:

(require 'emms-setup)
(setq emms-lastfm-client-username "myusername")
(setq emms-lastfm-client-api-key "myapikey")
(setq emms-lastfm-client-api-secret-key "mysecretkey")

Setting up emms-lastfm-client

Now, within emacs (taken straight from the docs!):

  1. M-x emms-lastfm-client-user-authorization - this will open a web page, asking if you want to grant access to the app (with the name and description you gave it when requesting the API key)
  2. M-x emms-lastfm-client-get-session - this is to store the authorisation key so you don't have to go through the authorisation process every time. If it doesn't work you might need to first create ~/.emacs.d/emms manually.

You're set! M-x emms-lastfm-client-play-similar-artists to select who to listen to :)

Useful tips

To stop the music: M-x emms-stop.

To remove the url display/track information:  M-x emms-mode-line-toggle (or -disable) and to remove the playing time information: M-x emms-playing-time-disable-display (they push the org messages too far out right!)

Other error messages

Some messages you may encounter along the way...

Contacting host:
progn: missing variables to generate handshake call

The documentation seems to suggest that setting a username is optional, but it's not. Make sure your .emacs contains your username in addition to the API key and secret key.

f: Don't know how to play track: (*track* (type . url) (name . "") (metadata))

emms uses an external program to play music, which is why you need to install mplayer or vlc.

Leave a comment | 4 so far

Balsamiq Mockups, oh, and Pinch too Pinch is a micro-blogging reader for on the N900

I like micro-blogging, or well, I hang out on anyway. I'd like to use it more but I have trouble keeping track when I add interesting-but-too-prolific people on my subscription list, or I sink when the occasional flamewar/"debate" erupts in a group I follow. I don't write a lot but I read, and I wanted the reading to be more efficient. The way I read at the moment is:

  • either through the web page, trying to find back the page where I last read a notice and then coming back slowly to the first page
  • or on XMPP, where if something came up while I was disconnected I can receive a huge heap of messages when coming online even though I may only have a few minutes available to read, and there's no way to mark where I stop if I only read through some of the notices.

Hm... You'd think there's a nice software announcement coming after this but there isn't really. This was the problem I set out to fix a few months ago and here I want to show how I used the wonderful Balsamiq Mockups software to wireframe my interface before jumping into the code (there is code though. You may skip to the end if that's the only thing you care about.)

Balsamiq Mockups

I've been using this for 18 months or so, and I really like it. It enables me to make on screen, in a nice readable way, something I used to scribble on paper before. The end result is something nice to look at that I can work from, and if this is software built for someone else I can show them (without any recoil of horror!) and make sure this is what they have in mind and that I'm not forgetting something glaringly obvious.

Let's go back to the micro-blogging reader. The first thing to handle was the timeline.

Wireframe of a fake timeline with messages and side-notes

The first time you use Balsamiq -- after the first 5 minutes where you will be amazed and clicking eveywhere (try it, they have a web demo on their site!) -- it will take a bit of time to learn where to find what, and what widgets exist. Soon enough though, you'll be making these nice wireframes about as fast as the crappy hand drawings.

You can have several mockups open in different tabs, which is useful when working on a sequence of screens or different parts of the same project.

As hinted at on that first image, Balsamiq provides widgets both for wireframing, as well as for annotations about the wireframe itself.

Wireframe of a single event, with the possible actions (reply, highlight, repeat), the follow-up screens and a post-it note

Here I use fancy arrows, and a post-it note. There are other elements like the curly braces from before or the round yellow numbers, to help call attention to differents part of the design. With the different containers and widgets you can easily mock up desktop, web and mobile apps. The font and general feel of the different elements is this way -- a bit unequal, not perfect -- to remind of hand drawing and avoid giving a slick, "finished" impression. It's still easy to make radical changes at this stage of the development, so that's the kind of discussions it should encourage (also, as opposed to say a realistic HTML mock-up, the customer/user is less likely to ask if it'll be done by next week since it looks nearly ready already!)

The third and last mock-up I made for the project was of the menu:

Nice and simple. Go give Balsamiq's web demo a try, you'll see how intuitive the interface is and then you'll remember it when you need it or wish for something similar. It's worth every penny ($79).

Now, what about Pinch, you ask? Well, the first attempt looked like this:

Initial maemo version

The wireframe was a very helpful guideline in remembering my goals and the big picture, to avoid getting lost in the details over and over again, though of course one should feel free to veer away when needed. On a touchscreen, a button with some text is a lot easier to click than just a small icon for instance. Also, the moving red line turned out to be a pain in the butt to figure out in pygtk so messages are simply greyed out and it's just as readable.

By the way, did anyone notice the glaring feature omission in the mockups? If not, maybe you're more of a spectator, like me...! I found out when attending an interesting talk wanting to share some good tidbit and... oops. There's no way to post a brand new message :) Ah well.


The app ended up being named pinch due to... a thesaurus really, never mind. At the moment it's really read-only: you get your messages, you mark them as read or highlight the stuff you want to deal with later. You can remove messages you've read. No replying or writing anything though. I still consider it technically usable by other people as my name isn't hard-coded anymore, thus it's possible to set up the app for yourself ;)

The main reason development stalled is that using the app is dead slow and I'm not sure of the best way to deal with it, and I haven't made the time to research how to handle this on a phone. There's a lot of waiting around looking at nothing while the app needs to grab URLs from and parse the XML. There are still a lot of interesting problems to solve (and I still need a nice reader-optimised micro-blogging tool dammit), so I should get back to it eventually.

In the spirit of the Myth of the Genius Programmer talk and other people saying the shame of sharing code goes away after a while, I decided to open up my GitHub repo (or perhaps it is happening because I haven't touched the code since June and forgot how terrible, terrible it is).

Resources or tips on making performance improvements for pygtk and/or Maemo apps would be so very welcome, if anyone has recommendations? :)

Leave a comment | 3 so far

LaTeX workshop in Tog

I'm back for more enabling! (Mwahaha) Seeing there was some interest in LaTeX, the very awesome Triona kindly offered to teach an evening workshop on the topic on September 21st, in Tog. Whether you're interested in starting out with LaTeX, or would like a refresher, join us! The registration information is available on Tog's blog.

- - -

Hello you! Do you know about something cool, relating to open-source or open culture or technology? Would you like to teach a workshop about it? Please get in touch!

Leave a comment