Canonical Voices

Posts tagged with 'english'

Victor Palau

Undeniably, a Long Term Support release is all about the maintenance. In the certification team, we will be focusing our efforts in the next release cycle on improving our Stable Release Updates (SRU) testing for Certified hardware.

While we get a fair amount of feedback on regressions introduced by proposed SRUs in clients, we do not hear very often from the Server community. Therefore have less idea on where to improve our testing. I would like to assume that this is because we are catching all regressions ;) but what are the chances of that?

If you are running Ubuntu Server, I would like to hear from you about your experience with SRUs and any serious hardware-specific regressions that you may have encounter? Anything that regularly goes wrong with SRUs that we should be looking for?

Thanks and look forward to discuss more with you at UDS-P!


Read more
Victor Palau

I have commented several times on the 2-weekly cadence that we follow at the certification team, but I haven’t gone into much detail on our 6 monthly cycle. We have just completed the Natty cycle (normally release date + 2/3 weeks) and we are about to start our Oneiric one.

6 monthly cycles help to plan achieving longer goals that drive the user stories implemented by the team in each iteration/sprint. During Natty, we had a loose coupling between these two.  I regularly (once a month) reviewed the progress of the Natty backlog and made sure that nothing was falling through the cracks. Despite the good completion rate in Natty, it was more of a case of the user stories forming the Blueprints (6 monthly requirements) than the other way around.

For Oneiric, the certification team went into UDS-O with much better defined blueprints. This has not only resulted in better sessions, but also on well defined backlog. Clearly, there is no much point trying to tight down what we will be doing in 4/5 months, so user stories towards the end of the cycle are vague and fairly large.  User stories for the next 2 months are better understood and described.

We have been collecting velocity data for the last few months, so by asking the team to roughly size new stories and review the sizes for the “next_iteration+1″, I hope to be able to build a burn up/down chart over the next few weeks! I will keep you posted.


Read more
Victor Palau

Thanks to Amber for doing this interview!


Read more
Victor Palau

Since we started the BugSquad, we had many people come and go from the mailing list, some of them show to the IRC sessions… however most of the ones that do contribute at least once (raising or fixing bugs) always seem to stick around.

It is my experience that making an extra effort to support someone’s first contribution is key to them becoming a regular member of the community. So, what are my “lessons learned” from the BugSquad so far:

  • Getting started guides – It is crucial to have detailed step-by-step guides for newbies, if you are trying to attract people from outside that might not have an in-depth knowledge of the project. For example, we realised that we didn’t have a simple guide on how to raise a bug. We had tones of detailed information on obscure Bugzilla functionality but nothing on the basics!
  • Make it simple (effort) - the more time that is needed to be spend downloading , installing and configuring stuff the less likely people are to participate. For example, we split the kits down to smaller download files, and reduce by half the amount of MBs needed to set up a running emulator.
  • Not everyone is you! - It is easy to assume that everyone sits behind a fast , reliable and unlimited broadband connection, that everyone lives in a country with out export restrictions… and so on. Today, our top contributor lives in Pakistan, he wasn’t able to join the bugsquad at the start as some of the required .zip files were export control. There wasn’t any better reason than we had never got around fixing it, as it wasn’t a problem for us. (btw, we’ve fixed the issue since)
  • With just a little push… – Actually, I found that most of the time , and once you have done all the above, many people just need a little push to make the jump. In the Bugsquad, I have found that many members would like the first bug or patch to be reviewed by one of the Symbian staff members before submitting it. They might have some reservations about the quality of either their soft or technical skills. Most of the time, they are perfectly capable of contributing, they just need to hear it from you. So , go on… give them a little push

I should point out that you need to have an eye on the long term here.. sure this might sound as more effort that is worth for that initial contribution, but it is all about setting the snowball rolling.

Also, I find that putting this sort of effort into helping people allows you to find out who really wants to contribute but they are getting stuck vs people that have a flight of fancy but are not committed. Hence, you build a sense of trust on the community members and get a hands-on understanding of what does it take to contribute to your project.


Read more