Information for New Assignees

Read Internal/Process/NewStaffTasks first. This page contains extra information over that.

There's a list of everyone with mugshots at MeetTheTeam. Phone numbers and other private information is available at

Communication is via IRC, email, and phone. Please do hang out on the #linaro channel and the internal #linaro-internal channel and feel free to ask any questions (How to set up IRC). If you want, ask Anmar about the shared Bip IRC proxy which lets you log and receive messages while offline.

Team Lead will set up a biweekly 1-on-1 call. The 1-on-1 is to make sure we talk. Status is already covered by other means. Our meeting and weekly schedule should be added in your Google calendar (with the conference call codes), if it is not the case, please ask the Team Lead.

Use the wiki to hold any thoughts, write-ups, or notes that may be useful to others. If the page is throw-away, consider making a sandbox under your name and putting it there. Pages can be shifted to the main tree later. See MichaelHope/Sandbox for an example. is available for sharing random files. See the Resources/HowTo page and file a RT ticket (RT HowTo) to get

Releases, Backports and Patches

The information below are outdated. This will be reviewed and fixed in our July Sprint.

Changes are normally done through Launchpad merge requests and are automatically built and tested by the cbuild auto builders. Benchmarks are automated but need to be manually spawned once the build has finished. Our main benchmarks have license restrictions and are discussed on the linaro-toolchain-benchmarks list. You're automatically in the group but need to enable the messages via the Launchpad editemails page. See WorkingGroups/ToolChain/Benchmarks and Internal/ToolChain for more.

Please note that we're moving away from CBuild towards the company-wide LAVA framework.

Changes are reviewed before landing. We run a review roster so there's at least one person responsible for reviews each week.

We release roughly in the middle of each month. The schedule is:

  • 1st of the month: FSF release branch merges are started
  • Week before release: last chance to land patches
  • Monday of release: release process is started
  • Wednesday: release process and testing is done, branch is open


We try to be as open and do things in an open way. Unless there is a good reason, such as confidential information being involved, please use #linaro, the mailing lists, and the public part of the wiki.

Send a summary of your activity at the end of every working week to the mailing list. A set of bullet items is fine. Please put [ACTIVITY] at the start of the subject line to make them easy to filter and sort.

The Connects and Sprints are very important as they're a great way to meet everyone involved, discuss new topics, and to get started into the organisation. The Connects s are in March and September and the sprint in July. See Events for more.

There's more information on the wiki. Especially read:

Day-to-day work

The information below are outdated. This will be reviewed and fixed in our July Sprint.

Work is organised through Launchpad bugs and blueprints. The linaro-toolchain project group shows all of the bugs across all Linaro projects:

You can also check individual projects:

Fixing a bug involves the following steps:

  1. Find a 'New' bug and assign yourself to it
  2. Once you have enough information to reproduce the problem, mark it as 'Triaged'
  3. Find a triaged bug, assign yourself to it, and mark it as 'In Progress'
  4. Create a new feature branch to fix the problem in named along the lines of lp-12345-fix-ice using bzr branch 4.5 lp-12345-fix-ice

  5. Fix the problem
  6. Make sure there's a regression test as part of the testsuite
  7. Update ChangeLog.linaro

  8. Commit the fix to the feature branch and tie it to the bug using similar to bzr commit --fixes lp:12345

  9. Push it up to Launchpad using similar to bzr push lp:~your-user-id/gcc-linaro/lp-12345-fix-ice

  10. Submit a merge request
  11. Andrew will pick up the request, merge it, mark it as 'Fix committed', and assign the milestone to where the fix will be released
  12. After the release, Michael will mark the bug as 'Fix released'

See BugProcess for more.

Blueprints are used to organise and track the work on new features. Each blueprint has a whiteboard which is overloaded to track the work items needed to complete a feature. Treat the blueprints as a living document that can have work items added and removed as time goes on. In most cases the whiteboard can also be used as a specification and notes, such as links off to supporting material.

Please update the blueprint status and work items at least at the end of the week when you do your activity report.



The information below are outdated. This will be reviewed and fixed in our July Sprint.

We have shared boards but it's worthwhile having some hardware on your desk.

Get a PandaBoard ES in a case from Special Computing. You'll also need some support hardware such as a USB to serial converter and some type of storage. Most boards come with a SD card but I recommend a fast USB flash drive or, failing that, a USB HDD.

See Internal/Hardware for a list of what other people have.

Loic, Michael, and some others have made their boards available over SSH. Contact them if you would like access.


The technical lead will follow up with you two weeks after joining. Don't be afraid to ask questions between now and then.

There is another review three months after joining regarding how well both sides fit together.

Quick start

The information below are outdated. This will be reviewed and fixed in our July Sprint.

There is a continious build at:


We generally mimic Ubuntu's configuration to make bugs found via Ubuntu easier to find. See the head of the configure log such as:

for how a particular build was configured. The configure arguments are currently:

  • --with-mode=thumb --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=neon --with-float=hard 

Marcin from the Foundations team provides a Ubuntu-derrived cross compiler. This is not the same as the latest Linaro compiler, as it includes the Linaro changes as a patch and a range of Ubuntu specific patches. It's best to build from source. The near term goal is to provide our own builds of just the Linaro toolchain via a PPA.

(See also Resources)

WorkingGroups/ToolChain/NewStaff (last modified 2015-02-23 16:30:10)