From Symbian Developer Community

Back to main Release Council wiki page

Contents 1 Agenda 2 Material 3 Attendees 4 Minutes 4.1 S^2 release schedule and how to declare Functional Completeness(FC) :(Victor) 4.2 Symbian^3 – Victor 4.3 TPIP List – SalvatoreR 4.4 Release Model – ratification – Victor 4.5 Delivery Management Status – Jim 4.6 RC Effectiveness - Mark 4.7 Agree schedule of RC meetings and next agenda: 5 Actions

Agenda

London- Foundation Offices (BST Time)

Updated Agenda

Durations are approximate

• 0830: Coffee & Pastries
• 0900: Welcome, agenda and introduction of new people: MarkS
• 0915: Review of Actions: MarkS
• 0935: S^2 release schedule and how to declare Functional Completeness: VictorP
• 1015: Break
• 1030: S^3 List of proposed features: VictorP
• 1115: TPIP list: SalvatoreR

• 1200: Lunch
• 1300: Release Model - ratification: VictorP
• 1330: Department update & feedback on 1st beta releases: JimC
• 1400: Discussion on RC effectiveness and suggestions for improvements: All
• 1430: Agree schedule of RC meetings and next agenda: MarkS
• 1500: Wrap up: MarkS/All

• 1800: Council Dinner

Material

• Release Plan - Updated version of the material presented by Victor
  
• Jim's slides

Attendees

Mark Skrebels, Symbian (chair) (MSk)
Anders Josefsson, SEMC (AJ)
Stefan Fager, Fujitsu (SF)
Philippe Gaudillat, STE (PG)
Philippe Peruset, STE (PP)
Philippe Lemoine, Symbian (PL)
Chandrashekar Challagonda, Teleca (CC)
Ilkka Korhonen, Teleca (IK)
Stephen Storer, Samsung, (SS)
Manabu Matsuura, DoCoMo (MM)
Seishi Tsukadi, DoCoMo, (ST)
Petri Poikolainen, Digia (PPo)
Riku Mettälä, Nokia (RM)
Laurent Le Gal, TI (LLG)
Urmi Shah, Symbian (minutes) (US)
Victor Palau, Symbian (VP)
Jim Clarke, Symbian (JC)

Minutes

S^2 release schedule and how to declare Functional Completeness(FC) :(Victor)

VP presented S^2 timeline slides (attached).

A releasable PDK is one that is smoke tested – validation of basic use cases. PP asked for rough idea of number of smoke tests? JC replied that it is in the 10’s as they are not functional tests, but basic use cases, used to validate that nothing major is broken.

PP asked whether it is possible to have test results from Nokia for S^2 build? SF explained the need to understand the level of quality of the release. RM replied that it would be possible to share TB9.1 test results, but Nokia internal build is not the same as SF build, TPIP is main difference so will need to filter results first.

SF asked whether all Symbian OS test code submitted? RM was not sure about all, but some automated test is included – issue with varied tooling for these tests (former Symbian, and S60). Tools are STIF and TEF. Some unit tests are included. RM added that if any other members had created additional tests , it would be good from SF point of view to contribute these. RM added that in future when more packages include their own automated tests, SF may be able to include some of these in their own test run.

LLG asked how to find feature list for Symbian Foundation releases (different to S60 published features) VP replied that Ian Hutton was working to come up with a Feature list from the F&RC. LLG suggested that RC should ask F&RC to give us a crisp list of features for S^2 making clear that it is a dry run for S^3.

LLG : Do we need a test coverage WG? Package owners have test framework and strategy. VP Part of quality group will deal with code coverage, but we cannot yet offer this (team + infrastructure ramp-up). JC stated that the smoke test is an automated one, which was contributed, and we are now looking to package level test contributions. The tool used to run the smoke test will scale up to run contributed package tests in future.

RM – Commercial implication of FC is that Public APIs are functionally complete. IPR permission given implicitly when contributors or other members contribute. MSk do we need to discussion this permission further? RM replied that this was given when members joined up. VP proposed that we publish the criteria for S^2 FC and the status, and do an online vote to agree this is FC. ACTION VP publish the criteria for S^2 FC and the status, and do an online vote to agree this is FC.

Third Party IP VP Proposed to divide all TPIP into two categories - those which are critical for S^2 and others (tgt S^3) in order to prioritise tracking and reporting at RC. SF asked who had created the list. VP The proposal is a start point which needs review and feedback from release council members – it has been reviewed internally in SF. Of the (proposed) critical list, R&D licences are signed for all but Helix, which is in late stages of negotiation. Of the (proposed) optional ones, R&D licence signed for Hantro video codec, others are in legal discussion. MSk asked why we don’t include these in statement of FC? VP replied that since they are 3rd party, so we are unable to test compatibility, and they are not available to everyone. RM stated that this ‘critical’ list shouldn’t reflect what is mandatory for commercial product, more about what is enough in order to use and develop on top of platform. SF have a list of required?

AJ - Is this aligned with TPIP list. JC subset of TPIP list. Things will not get dropped from TPIP list, timing may be a variable. VP will tie in back to Arch and RM Council. SF What proportion of packages will have been updated in S^2 compared to last release. RM – all S60 packages updated, mostly defect fixes, not so many of Symbian ones.

Symbian^3 – Victor

Expecting the first S^3 contribution from Nokia in August wk35. No earlier due to challenges of TPIP filtering. Then for S^2 and S^3, we will get fortnightly centralised contributions for the life of the product. By S^4, contributions will be direct from Package owners, and no longer centralised.

We have 6 months of S^3 deliveries – propose a shortlist of features to track and report to the council (proposed by Victor/Ian). There may be items added e.g. possible that SHAI will have deliveries into S^3. Some of these will definitely be delivered in S^3, others are not certain – we will engage with those and track them. RM added that about 50% of the list are in the initial contribution, the last four will come later. LLG questioned the Project Release Lifecycle – when will we have a ‘frozen feature list’ for the release? VP replied F&RC will come up with high level list for S^4, for S^3 F&RC will not drive list, but will review proposed content. Not much value in doing roadmap planning for S^3, as Nokia roadmap is frozen, unless someone else comes forward with proposed contributions. LLG asked, how do I know what the content of S^3 is – is it possible to extract the offering which is available in S^3 from the Nokia feature list? VP replied, this is available from the Technology Roadmap already (will be 100s of items). The RC will track at a higher granularity. LLG Symbian OS granularity was good enough (PREQ) for our needs. RM added, not yet able to have package roadmaps, but target dates for features for S^4 will come from F&RC. VP, We need to consider what we want as council members, not just as customers of S^3/4 since that detail is available for each package from the website. AJ noted, the list is good, but we need to have the ability to read the detail before this meeting. VP explained how you can look at the plan for a package using the SF website, and track it using bugzilla. He added that a link to bugzilla was available for about 20% of packages as a trial for key features for this release. There is a discussion thread relating to this.

VP requested that the council take a decision on to agree granularity of the list, the content can be agreed later. LLG requested the addition of a column listing whether feature is backward compatible or compatibility break. ACTION VP will start a discussion on the Forum about the criteria for functional completeness for S^3, including going to F&RC for key features. Please comment and will close by the end of next week.

AJ comment: Is the overall release plan now the plan of record? VP is happy for S^2 and S^3 to move to planned status (remove dotted lines around date). PP concerned that the initial roadmap dates showed release in Dec09, now Feb10, which doesn’t seem to comply with the spirit of the original agreement? When does the date get fixed? VP responded: difficult to change/fix date for S^3 when the contribution currently depends solely on Nokia roadmap. S^4 and S^5 will be much more in the spirit – can date be brought in? Difficult to do. VP repeated: for SF to understand what FC and hardened means, we need your (RC) input. MSk if we keep cadence of original release plan, we may need to sacrifice functionality. RM We need to know the reliability of the current plans so members can base their own roadmaps on them. Need to understand what is coming in earlier. S^4 should remain with dotted lines but have agreement from main contributors for S^2 and S^3 so can we remove dotted lines for these. AJ If we want a more aggressive shift towards bringing timeline into shape rather than expecting shift in dates, we need to do that when we start projects, bit late for S^2/3. Before we agree the dates, we need to agree what the steps are to determine FC e.g. Quality, feature list, feedback from contributors (Nokia). We should also ask F&RC to give a comment on S^3 – to test the process before we go to S^4. RM from a business POV, if the exercise even removes features from S^3 and the feature is non-config then is a bit late to change feature list. VP but the purpose is to get F&RC to provide us with what we need – first we need to tell them what that is, and they can have a go at giving it to us.

VP asked if we could at least agree on S^2? VP asked who was engaging with S^2 apart from Docomo and Fujitsu? SS – Samsung are planning to use it as we are still S60 5.1 users, so our comments and feedback can apply to both. SS Question: If we put our stake in the ground and agree date, we need to prioritise the features which are most important. PP No list of features on S2 – only query on test. VP but we need to have a plan date – to work to, which will drive the answers to those questions. Also, to get community to concentrate on testing and contributing test resources. LLG – i.e. window for user/customer to do integration/hardening before launch. DECISION: S^2 dates committed by June. For S^3 we will have a discussion on FC/feature list etc first, other related sub-actions will be determined with tgt dates available by end of next week – on forum. And go back to F&RC by end of next week. CC – should include HRP as part of FC features discussion.

TPIP List – SalvatoreR

Key message: For updates on status of TPIP, register on mailing list. Need feedback on content and format of the TPIP spreadsheet from users external to SF. Salvatore explained the spreadsheet: (key points only minuted) OS Tab: There are 81 items and constant input from all parts of SF is needed to ensure the info is updated accurately to send out weekly. Key columns include ‘priority’ (1,2 or 3). We are focussing on p1 items. ‘Impacted SF’ tells which release will include resolution to IP issue. ‘Foundation code release date’ gives our input to the RC tracking. ‘Status’ - will not be closed until we have contact details. Tools Tab: not much content Stats: have been aiming to get consistency on stats, so the criteria for closing items have now been constant for 4 weeks, and are being retrospectively applied to items previously declared closed. For help/info in the future: first sign up to mailing list. Ian Hutton ( involved in TPIP for a long time and chairs F&RC). Also from this week, a TPIP manager, Chris Davidson recruited.

MSk How is Priority determined? SalvatoreR - Based on urgency/release schedule. LLG SF have marketing given need-by dates to close IP the list? SalvatoreR - goes together with plan for EPL – Q2 next year. RM regardless of whether we get R&D licences or not how do we propose that community could work around IP issues? SalvatoreR - general answer not possible (can deal with specific issues). JC – ‘Free complete and competitive’ is the vision for the platform. The end of ambition is to seek a free alternative, it does not end at obtaining an R&D licence. Part of Chris Davidson’s job is to track the roadmap for this. The spreadsheet is a useful tool in the short term.

Release Model – ratification – Victor

We have already reviewed the release model in the council, but need to formally agree on the basic principles : on the model, and on the regular 2 releases per year. The basics are described in the email sent by VP in May 2006. DECISION is to agree to the model.JC asked whether we could agree our milestone definitions with respect to Symbian and S60 definitions? VP replied that these definitions would be created over the next few months.

Delivery Management Status – Jim

(Slides attached) PDK status: Not all member companies have downloaded kits – please do so, we are keen to get feedback, you can now report feedback using bugzilla. PDK initial feedback has been received. First key issue is complexity of download. We have tried to be responsive, with many fixes in place, some issues e.g. number of clicks involved in acceptance of different licenses, been worked through but no easy fix.

Also, lively web debate on the need for packaging tools. We would need RC to generate a proposal rather than SF doing it, in order get better requirements to make this change. Propose to set up a working group as it will not be straightforward. : SF has v basic solution, current tools could be improved No volunteers for working group.

We also need to approve (or change) the bug workflow – which was proposed by the Architecture council.

Delivery Update: Recruitment – most significant role to fill is test lead. Bugzilla defects from community being responded to by PO, showstoppers fixed, more process needed. Next steps: Most S^2 improvement updates are to make ease of build and use. S^3 – key issue is around graphics, esp important for non-members Contribution – we have at least one from non-Nokia which has tested the process. Hardware reference platform – this will target S^3, but perhaps it is viable to have some partial solution for S^2 in order to get H/W ref, if someone is willing to give it a try. CC – When will the first Symbian HRP be available? VP – target end August with S^3.

LLG – we can discuss offline to understand how we bring first PDK and HRP together at same time - joint effort, common tgt. Complex, but end Aug seems reasonable. VP Concerned that there are many new things in wk 35 timescale. LLG asked - can we phase integration plan – e.g. Build first with old graphics? JC replied that this 3 phase proposal needs to be broken into more interim steps.

CC - concerned about lack of HRP for S^2 – may come up again. RM - Nokia use their own h/w environment, product owners will have tested using this. VP - HRP not so much a validation platform, more a tool for developing. VP – if any members have need to get S^2 HRP, then are they willing to contribute to it, i.e. getting baseport? CC – will be happy to discuss, as long as there is a lead. VP main players are SF integration, TI, graphics team in Nokia (SOSCO have helped doing integration of graphics, if others e.g. teleca are willing to help, welcome!).

RC Effectiveness - Mark

How is the timing – Monthly with Quarterly face to face. RC members agreed that timing was OK. LLG suggested that we should keep as is but monitor, and if more momentum needed, we could increase frequency.

How they are run – suggestions? E.g. cross fertilisation between councils?

LLG – would be nice if each council shared key highlights and low light of last month, and included dependencies on each other.

JC - we have been in setup phase but now we need to be more proposal driven. Material should be available a week in advance if we need feedback on the day. We should be doing more offline.

SS - do we have a way of publishing to council members without publishing to all? Forum = public, mailing list = private, but backed up publicly. E.g. members only forum? JC – we are trying to be open, so would have to resist members only forum, the exception is info where data is possibly inaccurate.

RM – SF could provide a list of issues that people are asking SF to solve, but that SF believe are best solved in the community. Members and others could start to pick them up.

VP - this council needs to be more active – e.g. feedback on the agenda was low, but we all spend a couple of days here – surely you have more views about what you would like to see discussed? To make it work for us, we all need to express a view and work as a team.

AJ - cross fertilisation between councils is good e.g. a single feature is touched on in all councils, it would be helpful to be able to track it. JC – There is a proposals pipeline – see wiki. The default RC position on each proposal is that we don’t need to review it. But we may need to. (looked at SHAI proposal) MSk - perhaps agenda for RC (w.r.t. proposals) is to understand what major issues are being faced by other councils, and see if we need a view/involvement. LLG e.g. we may have some expectations for what the F&RC will give us when defining new Feature, we need to ensure they are aware.

VP – it will help to keep track of what is happening if you subscribe, is more stable and effective than email list.

LLG – it is difficult to get a quick walkthrough for all the information – to find out what are key top topics I need to look at? Maybe good to have one central dashboard of top 3 or 5 proposals/documents/discussions?

Agree schedule of RC meetings and next agenda:

Next meetings

Phone conf: July 24 meeting postponed due to holidays to August 5th 8am UK time.

Face2face: 27 Aug (remains) (Note correction to date)

Phone conf: Sept 24th 8am UK time remains.

Agenda for next mtg: (will need to prioritise)

• FC S2
• Proposal for MS defns
• Report on quality metrics group.
• Status update from council members on use of S^2
• Update on S3 plan
• Update on S4 feature set
• Perhaps f/b from members on how much time they spend on various councils

Actions

ID	Status	Action Description	Action Date	Assigned to	update
RC230409_3	IN PROGRESS	Jim/Victor clarify the difference between VT4 and functionally complete.		Jim/Victor	23/06: VP can make VT4 criteria received from Riku available to use as start point for group exercise to define Functionally Complete (FC). MSk added that quality also needs to be considered. LLG Does the quality group produce def of FC? VP clarified that the RC should lead discussion through forums and need quality group to advise on what is measurable. VP encouraged all RC members to post comments and engage actively on discussion board.
RC230409_6	CLOSED	Victor to initiate the following offline actions Milestone definitions - take to forums Quality Metrics – set up working group		Victor	Milestone defns - closed pending action RC230409_3: MSk will produce milestone defs material for review. Quality metrics - working group now set up. closed Requested
RC200509_1	CLOSED	Update the status and issues of providing list of components (content of builds) at next RC meeting. This is an issue that should be shared with the community.		Jim	23/06 some complexities in combining S60 and SymbianOS system models given restructure of codebase. List is now 80% correct – not yet complete or verified so shared with council members today but not ready for wiki. You can see which files belong to each package from S^1.
RC200509_2	CLOSED	Riku to send list of TB9.1 post-branch content and defect fixes		Riku	23/06 some TB9.1 changes were planned for post-branch from S^2 but actually included pre-branch, so no planned post-branch changes (of course this may change). Need discussion on process for injecting post branch changes as likely to happen in some release. VP asked when will we start to see posting of defects through bugzilla? RM believes Nokia have started to publish showstoppers. Burden on package owner reduced as they are able to link to bug description in Mercurial. LLG asked what process was used to take in new content. VP explained that package owners need to guide it, we measure code churn + use bugzilla to track features. SF have started working through examples with package owners.
RC200509_3	CLOSED	How are tools dependencies on new functionality known? Is that via the FRC? Jim to discuss and clarify within the SF		Jim	23/06 JC explained that the useful aspect of this action is ‘how do councils work’. If there was a disruptive toolchain change the request would come through Architecture Council, management of changes would come through the Release council.
RC200509_4	CLOSED	Jim to explain impact of OPENGL issue on emulator and HW and what we expect OEMs to do		Jim	23/06 JC - issue solved as 2.0b release of S^2 included workaround for Graphics issues which is explained in the release notes, and documented in bug31; Have ported an OpenGL open source graphics implementation to allow emulator to work. NVidia should not be an issue for emulator post S^2. But NVidia is a key issue for delivery planning in S^3.
RC230609_1	OPEN	Add agenda item for next teleconference: Process for including post-branch changes to release. (from discussion of RC200509_2)	05 Aug 09	Mark
RC230609_2	OPEN	Report on process for taking in new content at next council. (from discussion of RC200509_2)	05 Aug 09	Victor
RC230609_3	OPEN	Identify and publish technology area level test results relevant to S^2 from TB9.1 test results.	05 Aug 09	Riku
RC230609_4	OPEN	Get S^2 feature list from F&RC (IanH) and publish to RC	05 Aug 09	Victor
RC230609_5	OPEN	Give f/b on critical and optional TPIP lists over the next week.	03 Jul 09	All RC members
RC230609_6	OPEN	To capture the details of an integration plan for S^3 that includes the first PDk, Graphics and the Zoom2 baseport.	05 Aug 09	Mark
RC230609_7	OPEN	Create milestones proposal ready for next RC call.	05 Aug 09	Mark
RC230609_8	OPEN	Send out request for volunteers for Packaging Tools WG.	05 Aug 09	Jim
RC230609_9	OPEN	RC members to vote on bug workflow proposal posted in release council web (2 weeks).	10 Jul 09	All RC members
RC230609_10	OPEN	follow up putting HRP on plan, by next council mtg	05 Aug 09	Mark
RC230609_11	OPEN	create the top items dashboard ‘RC landing page’ – for group contribution. Key technical tracks which are being worked on etc.	10 Jul 09	Urmi
RC230609_12	OPEN	VP will start a discussion on the Forum about the criteria for functional completeness for S^3, including going to F&RC for key features. Please comment and will close by the end of next week.	1 Jul 09	Victor

Comments

Sign in to comment…