Ubuntu SDK assessment criteria
While the 13.04 cycle focus will not be on tooling for an Ubuntu SDK for app developers, we do want to kick off a discussion and ultimately define the criteria we will use to assess each one of the contending technologies and libraries we will include in a future Ubuntu SDK.
Also we want to discuss what a future SDK should include in terms of tools, libraries, etc.
Blueprint information
- Status:
- Complete
- Approver:
- Jono Bacon
- Priority:
- Low
- Drafter:
- David Planella
- Direction:
- Approved
- Assignee:
- David Planella
- Definition:
- Obsolete
- Series goal:
- Accepted for raring
- Implementation:
-
Informational
- Milestone target:
- None
- Started by
- Completed by
- David Planella
Whiteboard
Expectations
-------------------
- 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
Criteria
----------
- 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/
- 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
- Internationaliz
- Test coverage
- Data syncing
- Online accounts/
- Background processes/service
- User configuration/
- Tools/IDE/
- Metadata (see Tracker/NEPOMUK)?
- indicator support
- notification support
- app documentation
Alternative SDK proposal:
-------
There are two SDKs provided by another projects: Qt and GNOME. They both have good quality, but with small bugs. Qt SDK available since june 2010, and substantial part of developers and contributors uses Ubuntu
- We can form team for early adoption of QtCreator IDE.
- We can provide PPA with updated, but tested backports of Qt, QtCreator and other Qt tools.
- We can provide PPA with experimental Qt tools and addons: Qbs (Qt build system), QtCreator clang code model plugin, qdesktopcomponents, additional documentation for QtCreator in *.qch format like this: http://
- We can make recommendations for contributors and volunteers about important for Ubuntu things that we want see in future Qt and GNOME SDK releases. For example, many people want use QtCreator for non-Qt C++ projects
Work Items
Work items:
[dpm] Define a set of technologies to be assessed for an Ubuntu SDK: TODO
[dpm] Talk with bzoltan to identify any existing SDK assessment criteria that has been done recently and that can be reused for the current discussion: TODO
[dpm] Create a document that defines the criteria to assess the technologies an Ubuntu SDK should recommend and what it should include: TODO
[stefano-palazzo] Research the bindings the libraries we are recommending support: TODO
