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!
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!
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:
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”→
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).
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.
The above table is a section of the full integration plan for Symbian^3
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.
One of the areas that we are currently working on is the use of Bugzilla to track and manage the integration of new features into Symbian Platform Releases. I have set-up a few examples of real features in Bugzilla for Symbian^3. Here is how we are proposing to use it: