Talk:Task:2010 Agenda

(Moved from main page)
(Unsure)
Line 50: Line 50:
* Think of media server, VoIP, contact lists, camera, GPS localization. Currently developers only have the low level API's, while mostly they just want a widget that displays the mentioned data and listen to user interaction signal or device signals. This also makes these functionalities look the same in all applications using them
* Think of media server, VoIP, contact lists, camera, GPS localization. Currently developers only have the low level API's, while mostly they just want a widget that displays the mentioned data and listen to user interaction signal or device signals. This also makes these functionalities look the same in all applications using them
:''This is out of scope in the 2010 Agenda call. API and developer offering in general will improve and we might organize similar a similar brainstorming for that.--[[User:qgil|qgil]] 09:05, 2 June 2008 (UTC)''
:''This is out of scope in the 2010 Agenda call. API and developer offering in general will improve and we might organize similar a similar brainstorming for that.--[[User:qgil|qgil]] 09:05, 2 June 2008 (UTC)''
 +
 +
=== Eliminate porting and allow synchronisation with upstream distributions ===
 +
 +
A massive challenge and limiting factor for maemo is the lack of software that has been ported.  A great goal for 2010 would be to work out how to allow direct use of repositories from an upstream distribution (e.g. Debian testing armel) so packages do not have to be ported at all.  Initially this might only be for command line utilities, developer utilities, libraries, etc -- leaving GUI applications for a later phase.  There would still be a need for some ported packages, and some maemo-specific repositories to contain them, but the "long tail" of less frequently used packages would be made available.
 +
 +
Once this has been achieved, and a large number of packages are available, maemo should be able to be updated from the repositories chosen by the user: some users may choose to keep in sync with Debian stable, others with testing and some even with unstable.  This means that all packages (including system core packages like libc) need to be able to be updated (possibly with disclaimers).  Nokia could choose to create Nokia-specific versions of some core libraries if they want to avoid risk of library changes.
 +
 +
A further stage (probably beyond 2010) would be to work out how to allow kernel upgrades, without necessarily having to sacrifice the closed-source drivers for key hardware!  This could, for example, involve having a (limited) set of kernels available, with key closed source components rebuilt for them by Nokia, but not tied to ITOS release schedules.
 +
 +
The goal is to make the platform as useful as Debian is today, at least for those who do not insist on 100% openness.

Revision as of 20:13, 25 July 2008

Contents

Continuing the 2010 brainstorm

While the 100 Days brainstorm is almost closed and in its way for planning and implementation, we can continue brainstorming now for the mid term agenda. The 100 Days discussion was imho very good and we have got a concrete agenda with many subpages that now will need to get into details and execution. We should do something similar now with the Agenda 2010. Deadline? As you wish, latest in 100 days in order to present the plan in OSiM & the maemo summit.--qgil 20:14, 8 June 2008 (UTC)

This is not moving forward alone. Proposing to close the 2010 Agenda during the Sprint 2.--qgil 20:18, 28 June 2008 (UTC)

Out of scope

End-user software wishlist

Main article: Software wish-list

Software requests are really out-of-scope and not relevant to this brainstorming session. Please see the main article.

End-user software wishlist is really out of scope here, for the reasons explained in the 100 Days discussion page. Even asking for specific developer toos that are not web server based are not very in the scope of this maemo.org exercise.--qgil 13:34, 30 May 2008 (UTC)

So what is the scope for this long-term vision? How the community would like the *.maemo.org websites to be? What about the process that maemo the OS has been devloped (largely be Nokia)? A bit more explanation on your hopes on what this will achieve would be a useful steer, I think. --jaffa 21:40, 30 May 2008 (UTC)
Alright, what about this. maemo.org becomes "the best-in-class community for innovation on mobile devices running Linux". The maemo.org project is really community driven and in fact freedom to innovate is an essential part of its success. Nokia sponsors the project and helps in the parts where is needed, but doesn't stay in the way. What is on-topic in this brainstorm: the community objectives, dynamics, services, tools, etc, available in maemo.org - and what Nokia should do to leverage, empower, support them. To support you.--qgil 18:54, 1 June 2008 (UTC)

IDE

I'm maybe asking for too much but an IDE with

  • syntax highlighting and code completion for the major used languages (C, C++, Python, maybe Vala, along with their Hildon/Osso integration)
  • scratchbox building
  • directly build deb from IDE and post it to extras/devel
  • run testing on device through SSH

will greatly help developers. bundyo 20:50, 29 May 2008 (UTC)

Something like Eclipse and/or PluThon? generalantilles 21:05, 29 May 2008 (UTC)
I'm aware of all the Eclipse integrations, however i was talking more in the lines of a smaller/native IDE like Geany/mEdit. bundyo 21:19, 29 May 2008 (UTC)
Vala on Monodevelop with a standalone emulator (i.e. could we avoid scratchbox?) would be a dream. --boxofsnoo 15:18, 30 May 2008 (UTC)

Office

IMHO; I think that the idea of an office suite Is not something that belongs on an IT better support for google docs or something of that nature would be a better idea, you don't have to worry about different versions or storage space on the device... Thoughts? —Preceding unsigned comment added by 24.4.115.113 23:23, 29 May 2008 (UTC)

Please consider offline use! I don't think gDocs uses the screen space very well, and it's too slow for quick edits. The ITs need to walk the line between feature bloat and speed/accessibility. —Preceding unsigned comment added by boxofsnoo 11:20, 30 May 2008 (UTC)

Unsure

These are taken from the main page and perhaps go back there. They kind of mix software development with community activities.

Standards

The development for mobile devices forces the developers today, to focus on one target platform with one existing device. To give maemo a future, it will be essential to apply to existing standards, as well as work with other mobile projects to create new standards, wherever possible. Beyond the principal commitment to the GNOME Mobile stack and freedesktop.org standards, we have to formulate and support APIs and services for accessing and controlling the system functionality. Maybe a standardized DBus API currently rising at FreeSmartphone.org would the the right way.

Development Framework

  • Better GPS resources. (GeoClue???)
  • Development Tools and Utilities for Linux, OS X and Windows.
    • GUI development package (reduce learning curve)
    • Better feedback on testing of packages
    • make simple system for ideas to be tried
    • Better emulator on PC. Comes with most default applications of NIT and is based on a newer QEmu (at least one that supports Virtualization Extensions).
  • Better modern native languages support - like Vala and D. && how to build a hello world app in C++/Vala in 10 minute (no more!)
Let's take what is relevant of these points for the maemo.org community and online infrastructure. For instance "Better feedback on testing of packages" and "make simple system for ideas to be tried".--qgil 09:05, 2 June 2008 (UTC)

Ship high level building blocks

  • Think of media server, VoIP, contact lists, camera, GPS localization. Currently developers only have the low level API's, while mostly they just want a widget that displays the mentioned data and listen to user interaction signal or device signals. This also makes these functionalities look the same in all applications using them
This is out of scope in the 2010 Agenda call. API and developer offering in general will improve and we might organize similar a similar brainstorming for that.--qgil 09:05, 2 June 2008 (UTC)

Eliminate porting and allow synchronisation with upstream distributions

A massive challenge and limiting factor for maemo is the lack of software that has been ported. A great goal for 2010 would be to work out how to allow direct use of repositories from an upstream distribution (e.g. Debian testing armel) so packages do not have to be ported at all. Initially this might only be for command line utilities, developer utilities, libraries, etc -- leaving GUI applications for a later phase. There would still be a need for some ported packages, and some maemo-specific repositories to contain them, but the "long tail" of less frequently used packages would be made available.

Once this has been achieved, and a large number of packages are available, maemo should be able to be updated from the repositories chosen by the user: some users may choose to keep in sync with Debian stable, others with testing and some even with unstable. This means that all packages (including system core packages like libc) need to be able to be updated (possibly with disclaimers). Nokia could choose to create Nokia-specific versions of some core libraries if they want to avoid risk of library changes.

A further stage (probably beyond 2010) would be to work out how to allow kernel upgrades, without necessarily having to sacrifice the closed-source drivers for key hardware! This could, for example, involve having a (limited) set of kernels available, with key closed source components rebuilt for them by Nokia, but not tied to ITOS release schedules.

The goal is to make the platform as useful as Debian is today, at least for those who do not insist on 100% openness.