smartphones-userland@linuxtogo.orgHeyho,
the last days I thought a little bit about our current development for
FSO and SHR and I am not very happy with it.
But first, how do we develop FSO and SHR from my point of view: We have
the problem to target several devices which are mostly unknown when we
get them in our hands. There are several problems with each device
(N900: Battery, ISI, ... Palm Pre: Modem, ...) which needs a lot of time
from one or more developer to be initialy fixed. After that or in
parallel we starting with machine support in OpenEmbedded and try to get
all features we want working. No plan, no release cycle. Beside this we
implementing new features depending on how much time one developer have
beside this machine specific work in SHR or FSO.
You might see which problems I see with the current process: We know
what we want to have in the end or do we don't know it? To generalize
it: We want a smartphone running FOSS only (with maybe some exceptions).
What this means is open to everyone and everyone has their own idea
about what a device running FOSS only is.
We are know at some point in time where we have two devices, the N900
and the Palm Pre which are quite good target plattforms for both FSO and
SHR. But what now? Where do we want to get with them? Yes we need basics
smartphone functionality on both devices like GSM, WiFi and so on. But
what are our aims for the next year? What do we want to archive? We
should define it! Until now there is now real release version of SHR or
FSO as we don't pointed out what a release should have to be a release.
My idea is now: Let use define some release cycle and release maybe at
two times a year a new version of SHR/FSO which has features we define
when we starting developing the new version. For example: Next release
should be 2011.04. Now we define which machines should be supported by
this release and which features we want to provide. This can be the Palm
Pre / N900 device with basic Call support integrated in FSO and SHR. We
define this as a feature of this release and work until 2011.04 to get
this stable and usable for the user. All other features like SMS are not
part of this release. If we can define such a release cycle we know
everytime on what kind of features we are currently working.
If we start with planning the next release everyone from the community
can speak up and propose their feature for the next release. The release
team then chooses the features part of the next release and puts the
release data (start, end, which features/bugs are included, who works on
what) somewhere in the wiki and open new milestones, work items in the
trac system.
Every release should have it's own branch of OE metadata for example. So
we can some stable release which we can support (if we have somebody who
wants to do that) until the next release is out.
The text above maybe some kind of unsorted and written down very quickly
and is just here to start the discussion in the public about what we
want to archive with FSO/SHR in the future and how we will do it.
regards,
morphis
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
