MeeGo SDK team meeting in Dublin, 17.11.2010
Session 1: overall direction and SDK plans
Participants: Santtu Ahonen, Kamal Bhatt, Fathi Boudra, Uli Dumschat, Veli Kaksonen, Ville Lavonius, XXX Lv, Mark Skarpness, Kevin Smith, Bob Spencer, Titta Väyrynen
- ONE SDK (MeeGo SDK = Qt SDK + MeeGo plug-in)
- New stakeholders should be able to bring their own toolchains, device images, sysroots easily to the main SDK. No changes to Qt Creator should be needed.
- Transparency to Qt roadmap and process is a must.
- Biggest markets exist for Windows and MacOS. Support for different OS versions has already been narrowed down to save testing resources.
- Priorities:
- 1)Windows 7
- 2)Snow Leopard
- 3)Ubuntu Maverick 10.10
Concrete plans (most for/relevant to MeeGo 1.2)
- Qt Creator to be made extendible for tools from both Intel and Nokia
- Planned Intel additions include, for example: IOS translator, which is a tool for translating APIs into MeeGo APIs; AppUp specific tools. These will be closed-source tools available for everyone.
- Timeline for Intel compiler in MeeGo SDK: beta q2/11, final q3-q4/11
- Madde is currently gcc-oriented so the SDK team needs to learn how to integrate the compiler to Madde. Integration is needed for developers to be able to use the compiler through the SDK.
- Is switching compilers possible? -> editing (adding libraries) is currently possible, but not user-friendly.
- Multiple debuggers are going to be included in IDE
- What to agree on investing on emulator support for Windows and MAC? -> One QEMU within the MeeGo 1.2 timeframe from Nokia
- Simplify test/debug environment selection: Qt Simulator as default (updates would be needed to broaden the functionalities, but would including MeeGo-specific functionalities disrupt the Qt story?), Emulator as an option
Open issues & to do
- Define model for how a developer should define (on SDK) target devices on the SDK and MeeGo release s/he want apps to be compatible with.
- How to avoid duplicate work between Intel and Nokia? This is partially CPU dependant, so cannot always be avoided.
- How should device support be organized (Nokia and Intel plan to restrict support to their respective devices)? -> Commercial third party?
Santtu: Nokia (Qt) preparing to take the initial contacts from developers and helping them find the correct contacts (to be discussed with Valtteri and Imad)
- Define rules of engagement for device manufacturers!
- Define release quality criteria: how do you get your tool to be visible in SDK?
Scheduling, delivery, release process
- SDK maintenance tool -> whenever individual tools a developer has installed are updated, the updates should be promoted on the front page of the MeeGo SDK. Developer should also be able to initiate a check for updates through the SDK.
- Individual tools should include info of their origin (company).
- How to deliver? -> MeeGo page for finding SDK and content (landing page); Qt tool physical location in qt.com and other components from Meego.com -> developer still perceives this as one installer.
- Who takes the responsibility of creating this 'super-installer'? -> co-operation of MeeGo SDK team: Linux stream, Windows stream, and MacOS stream.
- Currently Qt team working on the installer (for Nokia parts)
- All plug-in area deadlines cannot be shared openly even inside the SDK team, this makes roadmapping and scheduling more difficult.
- Do SDK releases always go hand-in-hand with OS releases? -> No fixed decision on this.
- Fathi named as MeeGo SDK release manager. He joins the release engineering team working group meetings (every week Tuesday at 11 Portland time)
- SDK-specific parts managed by Fathi
- Components going to repo are managed by the Package owner (Rolla + Sascha)?
- Detailed responsibility division agreed in the release engineering meeting.
- Who owns the toolchain?
- Veli: Linux as the baseline -> porting teams for Windows and MacOS (both lead by Fathi). (This is the way we should do it for all the tools, not only for toolchains (added later by Veli))
- New potential verticals during 2011: if not in release engineering plans, not supported
- Feedback from conference: flexibility of sysroot/extendibility - too difficult. QEMU does not work on all systems where it should
Open issues & to do
- Responsibilities to be decided for Windows and MacOS
- AP Veli: Define a common process for creating images. Veli + Veli-Pekka Vatula have discussed this, Rolla responsible for Intel side? Core image is the basis from which other images can be created.
- API lifecycle and categorization: No decisions on this, yet(?) See presentation by Santtu
Session 2: team meeting
MeeGo 1.1 lessons learned
Positive
- team - communication worked well
- release was successful
- end-result was reasonably good
- October changes were patched in doc fairly well.
- people are active
- good communication daily
- good cooperation, flexible team members
- also outsider support at last minute
- common view inside SDK team on priorities
- main goals were reached
- reviews held for doc despite changes
- vision clearer now after talking with people
- progress in QA, especially with reports
- openness has improved but can still be improved
Improvement areas and suggestions
Improvement suggestions in italics
- Release planning took time (Qt mobility backends as an example of a confusion)
- No f2f meeting
- Getting the release out was long-winded. List of reviewers kept growing and so did AP list -> agree on release check list. Assign owner + approver (who is a single person).
- All action points were not clear and this led to frustration
- Changes came late, which created peaks in workload
- toolchain deadlines would have been needed well in advance
- roadmap was missing; no visibility to release scope in the beginning -> figure out scope first (Done for MeeGo 1.2).and separate must have /nice to have
- no visibility to SDK team structure and surrounding people -> assign definite roles, list all persons involved on one wiki page
- some issues could not be discussed in public -> use M2 site for this purpose, access for whole team
- decisions that led to extra work had to be made ad-hoc without a chance to consult all the people or teams affected -> risk management meeting for recognizing potential issues in advance?
- staying in IRC channel can be a challenging -> use also emails/mailing lists
- map urgent things
- process level of MeeGo program -> we could do better if Bugzilla/Featurezilla were properly used!
- automate a part of the testing (e.g. Ubuntu installation + a few basic tests)
- more emails to mailing lists for sharing the plans with community
Improvements already agreed on
- Release-specific: Document the items that the team can't do and ask help from community!
- General: Document the items that the team would like help to from community! (check e.g. "kde junior support", "junior jobs")
- Non-functional requirements to Featurezilla, too. E.g. plans on testing tools - include as a part of the quality criteria for 1.2
Other items from wiki agenda
GTM activities
- Process and schedule: Release manager tags to Featurezilla -> group managers go to Featurezilla and set the milestones for target reqs.
- Architecture team to include:
- 'Simulator and emulators task force
- API task force (cross-team task: What is there? What is the message?)
- Toolchain task force
- MADDE
- A new Go-To-Market role needed: a channel between marketing and SDK, driving the release as a whole. Participation from the beginning, looking at requirements as well, owning a list of marketing related items to be delivered. -> Ronan proposed
- Doc lead: Titta -> NN Doc lead backup: Elliot/Ronan
- Windows team lead (Kerry Jiang leads, Al Nikolov in team)
- MacOS team lead (TBD/H)
- Toolchain lead: Jarmo Kant (to be checked), Jackie Wu as backup
- Madde, installer and Qt simulator -> Intel participants to be included in these.
- For component package maintainers: Jackie/John for owners of a part of the packages?
- Owner needed for Qt creator plug-in to use OBS (Frank Karlitschek who has created a first version to be included if possible?)
- QEMU team provides all these:
- Windows QEMU acceleration - no further investment from Intel
- Mac QEMU - (TBD/H)
Open issues & todo
- AP Veli: take forward the API task force idea.Nokia: Janne Sormunen??Intel: NN
- Go to market role + team lead
- Doc lead backup (+ new lead latest in Feb)
- MacOS team lead (TBD/H)
- Mac QEMU - (TBD/H)
- AP Veli: check toolchain lead situation
- Owner for Qt creator plug-in to use OBS
Next meeting
- Next face to face meeting in January 2011, location Helsinki.
- Follow-up face to face meeting in April 2011, location Portland