• We want to kick off the discussion about the criteria to choose to decide on a future SDK
  • We're not going to work on an Ubuntu SDK this cycle
  • We want to discuss what an SDK should really include


  • Integration with Ubuntu (which bindings would be required?)
  • Language/Toolkit support or potential for it should be considered
    • (for example: Python bindings for Canberra sound playing)
  • Form factor support & performance

  • Availability of documentation
  • Stability/Maturity/Support life
  • application sandboxing
  • abstraction from actual implementation

concept of a 'well-behaved' app that uses all recommended approaches an therefore is likely to work well on the wide range of form factors

clear statement of support period for apps that implement recommended APIs

Provide some guarantee of support lifetime, minimum amount of time in deprecated

(I would also make it clear that no component of this SDK can be "Ubuntu only". Anything built against the SDK must be buildable on other distros too. Otherwise we're causing bad disruption that will just scare off devs. -afeder)

What should an SDK include?

  • API set
  • Root file system + container (debatable whether this should be included or whether the SDK should be released as applying to specific Ubuntu release)
  • Toolset
  • Ecosystem (back end)
  • Whatever supports the app lifecycle
  • Documentation

Areas of coverage

  • GUI
  • Audio
  • Video
  • Networking / http I/O
  • File I/O
  • Localization
  • Accessibility
  • Internationalization support
  • Test coverage
  • Data syncing
  • Online accounts/credentials
  • Background processes/service
  • User configuration/settings
  • Tools/IDE/Compilers/Packaging
  • Metadata (see Tracker/NEPOMUK)?
  • indicator support
  • notification support
  • app documentation

Work items

  • [dpm] Cre
  • [stefano-palazzo] Research the bindings the libraries we are recommending support

UbuntuSDK (last edited 2012-10-30 05:21:58 by afeder)