Tag: bugzilla

Symbian^2 Success Story: 24 Contributions and Counting

If you have been following the Symbian world, the latest  hot news is the announcement of the first Symbian^3 phone by Nokia (the N8).

However, between Symbian^1 and Symbian^3 there is missing number –  so what is it going on with Symbian^2?  While Symbian^2 is not a revolutionary step in platform functionality, it is in terms of Open Source working practices.

Despite the fact that Symbian^2 remains SFL, and hence its source still open only to members, there are currently 24 contributions from non-Package Owner companies that have been accepted into the MCL, and another 50 still going through the review process.

So why is this important? Firstly, because it clearly signals the willingness of Symbian members to make source contributions and to improve the overall quality of the platform.

Secondly, because Symbian^2 is a foundation release and most of these quality improvements are still relevant for Symbian^3.

Kudos goes to DOCOMO as the main contributor and to all the package owners that are providing feedback and managing these contributions. To all of you: Thanks  and Keep up the good work!

Mylyn – Why it is worth upgrading to Tasktop

I have been using Mylyn now for a while and it has been great to help keeping on top of large amounts of bugzilla entries. I’ve used it to manage the integration plan for the Symbian platform, which describes the expected contributions into the platform.

One of the benefits that Mylyn offers developers is the reduction on Context Switching. Context switching is not only costly for software programs, but also for humans working on concurrent tasks. Mylyn provides a great integration with the IDE that allows developers using Eclipse to substantially reduce the wasted time on switching between application and work tasks.

However, I am not a developer… so Mylyn did not really provide me with any improvements in this area. Hence, I decided to download the Tasktop 30-day-trial standalone version and see if I could have get some time-saving by exploring the additional features for “Task Context”.  Here are the results:

The first obvious advantage is that it doesn’t really load all the rest of Eclipse/Carbide functionality that I don’t use and that eats a substantial amount of my manager’s-spec laptop memory. Hence, the first improvement is better working speed!


 Continue reading “Mylyn – Why it is worth upgrading to Tasktop” →

Bug 322 – Anatomy of a Symbian Contribution

Today I wanted to blog about the contribution infrastructure that we have set around contributing fixes or enhancements to the platform. As a practical example I would like to trace the steps of BUG 322.

BUG322 describes a simple export error from a bld.inf file, and it was identified by Simon Mellor from Accenture. Simon reported the bug, and provided a patch with a proposed fix:

This is how bugzilla displays the patch attached to the bug

Next the Package Owner (Sampo Savolainen from Nokia) reviwed the proposed fix and accepted it as valid. At this point Sampo applied himself the patch to the MCL. As the Package Owner, he is the only person that can do so (unless he has delegated the activity to a commiter).  Although Sampo is the one applying the patch the Kudos and the responsibility goes back to the original contributor. Here is what Mercurial has to say about that: Continue reading “Bug 322 – Anatomy of a Symbian Contribution” →

Integration Plan (part 1)

Recently I blogged about using Bugzilla to track features. I am happy to report that things are moving forward really well thanks to the community and Mylyn. We now have created the high-level delivery plan for Symbian^3 in Bugzilla, and completed the details for one of the key features: New Graphics Architecture (NGA – aka Screenplay).

intp3

As you can see from the picture, Mylyn makes it really simple for anyone to keep an eye on the plan.

BUG_ID 176 is the top level entry for NGA. In this post, I won’t go into the specific details of NGA, but explain the next step that we are taking in our planning: The Integration Plan.

Having all this data in Bugzilla allows us to build a good view of  the progress of a specific release. As we do not want to be monitoring every single submission, we have decided to follow the implementation of  “Key Features” (we are currently discussing the key features for Symbian^3)

The aim is to extract all the good information provided by the package owners and put into a format that facilitates the analysis of the health of the release. Taking a leaf from the Agile book, and introducing a 2-week regular heartbeat for our kits releases and tracking feature increments against it (for regular kit updates click here).

Also, any data beyond 6 months from “today” is displayed in quarters since we need to remain flexible and responsive to change (a “scaling agile” practice). Hence, it is understood that the detailed plan beyond 3 months will be fluid and beyond 6 months is only an indication of intent.

It is  probably worth noting at this point that the integration plan is based on voluntary contributions, and that we aim to increase the confidence in it by promoting frequent stage deliveries and asking the contributors to provide regular updates when changes occur.

intp1

The above table is a section of the full integration plan for Symbian^3

Continue reading “Integration Plan (part 1)” →

Quality Metrics

Measuring SW quality can be complicated, even for a chipmunk

Maintaining the current high quality levels of the platform assets is a big priority for both our members and ourselves.

In the past, Symbian Ltd. did a good job at understanding how the software maturity was evolving and when the platform would be ready for releasing. Moving to open source has changed the sources of information available to us and their reliability. So, can we still measure the quality of our platform?

To answer this question, the Release Council launched a working group, back in June, that has identified a set of initial metrics for the job.

Continue reading “Quality Metrics” →