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

1. 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.
2. How to avoid duplicate work between Intel and Nokia? This is partially CPU dependant, so cannot always be avoided.
3. 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)

1. Define rules of engagement for device manufacturers!
2. 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

1. Responsibilities to be decided for Windows and MacOS
2. 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.
3. 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

1. AP Veli: take forward the API task force idea.Nokia: Janne Sormunen??Intel: NN
2. Go to market role + team lead
3. Doc lead backup (+ new lead latest in Feb)
4. MacOS team lead (TBD/H)
5. Mac QEMU - (TBD/H)
6. AP Veli: check toolchain lead situation
7. 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