Canonical Voices

Posts tagged with 'canonical'

Victor Palau

Why Work For Canonical

Excellent video on why working for Canonical is great! enjoy.

Read more
Victor Palau

Some of the work done to enable Sandybridge Suspend (S3) and Hibernate(S4) showed how painful it can be to get hardware to do what it oughts to do! The problem arises when you find yourself with not many tools to debug what is going on, since your console and half of the OS functionality has already gone to sleep.

BIOS Vendors rely on the use of expensive JTAG debugging tools. While this is ok, it does not really allow for the community to participate and considerably increases the cost of enabling a system to work with Ubuntu.

Faced with this problem, the Hardware Enablement team at Canonical has set themselves the goal in Oneiric to create a “tool to analyze and suggest where suspend/resume is failing to help guide people through debug phase” i.e an automated version of Colin King.

The basic idea is going back to debugging basics: “Have you hit that print statement before dying?”. The problem is that you are trying to instrument a fairly complex part of the systems and you do not have a screen to print stuff to.

For the first problem, the team is trying an ready available open source solution: System tap. For the second problem, they are going old school: Audio and Light signals. Today most systems have speakers and a few LEDs to let you know one thousand irrelevant things that you can do with your keyboard. So why not put them to good use?

The blueprint goes beyond a simple “BEEP” when you hit your breakpoint :

We would need some hardware to record the lights/sound at a sensible speed:

  • Have another PC record the audio and interpret it
  • Leverage ham radio code already done to interpret sound

With some initial prototypes already floating around, I can’t wait to see what they deliver!

Read more
Victor Palau

Working with a fully distributed team has made me appreciate the beauty of having face time with your team!  Hence, I took the opportunity at UDS to get more acquainted with my colleagues.

Scrum by DarkMatter

As a first part to introducing Scrum to the team, we defined the high level goals (or Epics) for the 6 month release cycle. Part of what I have been trying to figure out is how to use the tools we have at-hand to get started. For the 6 months sprint backlog, we finally settle on launchpad blueprints. We are basically using a planning project within Launchpad, that will have a milestone per sprint/release. By prioritizing and assigning blueprints against the milestone, we get the backlog view.

Back at Symbian, we started by setting up daily scrums and weekly iteration backlogs. However, once the machine had started we struggled to define long term goals. It is hard to get out from the 2 week mindset.

Hence, with HW certification team at Canonical, I decided to prioritise the longer term goals. This was made very easy by the regular cadence of Ubuntu releases. The next step was introducing daily scrums and a 2 week iteration cadence within the 6 months sprints.

Are you standing up at the other end of the line?

With a fully distributed team, introducing regular formalised communication seems on paper an easy win. However, the trick is in the implementation. How do you do it? We decided not to have IRC meetings, based on previous experience. Eventually,  people did not read the comments from others and waited until their name pinged in the IRC channel to post a pre-baked update.  Another option was to Mumble our way through it!

Mumble is widely use in Canonical, so I thought – why not! The first day was short of a disaster. At least 2 people from the team never made it. We had so many issues with headphones not working, that we finally started 10 minutes late – quite bad for a 15 minutes meeting.  I think Mumble is one of those systems that gets better the more you use it. So we will keep our weekly meetings in Mumble, but it didn’t cut the mustard for daily scrums.

Another point against Mumble is the global time zones.  It is great to use computer based systems, if your computer is already on, you are ready for your day and so on… However with people in Asia, US and Europe, the daily scrum is always going to be outside someone’s core-hours.  We settled on a phone conference bridge. So far is going great! We did fail victim to the different daylight savings switch-days between the US and Europe. Can someone explain me why, oh why!?

Iteration Backlog and Task Board

Having proven at Symbian that the all mighty Google-excel was able to deliver a usable Iteration Backlog, I proceeded to extended to host a Task Board.

The important thing is to remember what task board are about – visual aids! Ours is colourful and simple. It has a columns for  ID, Title,  Assignee, Not Started, In Progress, Blocked and Done. The last four are brightly coloured cells that can be easily copy&pasted. What can I say, it doesn’t beat the real deal but this will do for the moment.

Next episode – The Demo and Planning sessions!

Read more