If you have been dowloanding code from the mercurial repos, you would have notice some spooky coincidences… most package MCLs update all at the same time!
Well you can relax, our repos are not posses. This is the result of Nokia’s package owners delivering contributions to our repos in a centralised manner.As you can imagine delivering updates to over 30 million lines of code every other week is a rather complexed operation.
We have been Working with Nokia to improve the contribution channel to make it reliable (we now consistently recieve contributions every 2 weeks). We are now moving towards the next big step, an automated package-base publishing system. You can now see the first live pilot on the access security package repo. Continue reading “Improving Code Contributions”→
I have previously blogged about the quantity and quality of features that the community is planning for Symbian^3, but how about Symbian^4?. Let’s have a recap on where we are today!
Symbian^3 is almost there
Symbian^3 is nearing Functionally Complete (FC is in Q1 2010, likely to be February) and the contributions have come fast and thick over the last month. Of the 43 package feature tracked in the integration plan for Symbian^3, 30 have already been contributed to the foundation code line. These are:
Multipage Homescreen – Provide multiple home screen supports
3PC – Bearer mobility support in 3PC and adoption
WDP – Proven Writeable Demand Paging platform support
HD video – Support for files of over 2GBs that will enable HD video
One-click connectivity – Simpler connection dialogue that requires one click only
Song recognition and music store integration with radio application
Remote contact look-up – plug-in framework to allow easy integration of remote contact look-up
You should expect all of them to be included in the S^3 PDK3.0.f (planned for week03). In addition, QT for Symbian is now available from the foundation repositories under LGPL and it will be included in future PDKs (Product Development Kits).
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!
With the aim to share and highlight as much relevant information as possible, I would like to bring to your attention the week44 Release Plan! We have regularly published updates to release plan since May(ish) in the Release Council. In an effort to bring it up to the surface, we have created a landing page for it.
I have refered on the past to the capability of reporting metrics against the Symbian Platform. Finally we are there!
This week the team produce the first snapshot of Bug , Code size and Code Churn with real data. The snapshot is to be presented on Friday to the Release Council for feedback. Let’s have a look at it in more detail:
These are graphics auto-generated from Bugtracker Metrics, it allows you to drill down to as much detail as you want. The data in the snapshot is frozen from an specific date, but you can re-run the queries live from the bugtracker metrics interface.
Now that we can measure it, we can start introducing some standard defect management practices.
One thing I keep getting asked is “where do you get the data for the integration plan?”. In the past, I have mentioned that how features are added to integration plan, but from today I am publishing together with the pan: the raw data used to create it, the scripts that provide the data and filters that we used to manage the information available.
Every person has a different risk profile. This is the willingness of that person to take a chance to achieve a reward versus the probability of failure. The amount of risk we are willing to take seems to be correlated to the reward promised and the time frame associated to it (i.e. will I get teh reward tomorrow, in 2 or 10 years). Risk profiles of companies are somehow a weighted average of the risk profiles of their employees. Hence, different companies (even in the same market segment) have different risk profiles. Continue reading “Risk Analysis – Integration plan (part 2)”→
Today just a quick update on integration planning..Over the last few weeks, we have been working on providing a bit more clarity on what artefacts are we use to plan platform releases, and how do they related to each other:
In a nutshell:
We produce a platform release plan that provides implementation details to the Platform Plan (roadmap)
The Platform Release Plan contains plan per active S^n release
Each Release Plan is informed by the Integration plan and the Test and Quality Plan (not yet available)
The Integration plan is derived from the information available in package backlogs and feeds into the kit schedule
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