Stable Hybrid Release

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Tasks & status)
(Architecture)
Line 130: Line 130:
  
 
=== Architecture ===
 
=== Architecture ===
SHR uses FSO to interface to the hardware, so see the FSO architecture documentation, too.  For how the openmoko*3 applications that SHR forked off 2007.2 access FSO, see http://www.calaquendi.org/om/ophonekitd.png.
+
SHR uses FSO to interface to the hardware, so see the FSO architecture documentation, too.  For how the openmoko*3 applications that SHR forked off 2007.2 access FSO, see http://img117.imageshack.us/my.php?image=lfiv9.png
  
 
== List of packages included ==
 
== List of packages included ==

Revision as of 21:24, 15 September 2008

SHR is one of the many distributions that currently work on the Openmoko phones. You can compare a distribution with an Operating System on normal computers. It gives the phone all the software needed for operating. For more information about the different flavors, see distributions. Template:SHR

Contents

Overview

The Stable Hybrid Release (SHR) is intended to be a combination of the FSO, some of the Openmoko2007.2 GTK software, and the ASU that provides all of the functionality of the 2007.2 software, but with the stability of the FSO and the new GUI toolkits provided by the ASU. It will probably be based on an ASU build, with the FSO software and GTK end-user apps added.

(We're not married to the idea of using the GTK apps, but they already exist and are more-or-less debugged at least on the UI side. If someone knows of a more stable and/or usable app that's appropriate for the OM, let us know by dropping a comment on the discussion tab of this page.)

Follow the project here: SHR Project Homepage

Why SHR exists

This is long and rambling, and maybe more of a tirade than information, but it does give some background on why this project was started. The overview gives, well, the overview, this is more of a deeper examination of the existing releases and why we felt we needed something new.

Feel free to skip this whole section if you already think SHR is a good idea :-)

Why not ASU?

ASU is the distro that OM is putting their main effort into right now. ASU looks very slick, but is very unstable right now, and is likely to be unstable and feature-poor for some time.

Why not 2007.2?

2007.2 is the "old" Openmoko distribution, now unsupported. Unsupported == often broken. Also, neither calls nor suspend/resume ever worked reliably.

Why not Qtopia?

You can also install Qtopia on the phone.

Qtopia is stable but you can only build qt apps on Qtopia, which means lots of linux apps you might want to port suddenly got a lot harder to port. And some people just don't like developing for qt.

Also, as far as I know, there is no documented build procedure for Qtopia on Openmoko.

Why not FSO?

FSO is the initiative by Mickey Lauer and crew to create a good D-Bus infrastructure which runs on the neos, among other devices.

FSO is by far the most stable & usable release, if all you want is a phone. (I mean *all*. It just has a dialer right now, not even call history.)

FSO is never intended on its own to be a full image, it's just the infrastructure and a demo app.

Other people are supposed to put a front end on FSO. So that's what we're doing.

Why SHR?

So SHR is FSO, with us doing the necessary work to port the old high-functionality 2007.2 stuff on a stable call platform. We have an adapter from the 2007.2 call service to the FSO call service and we're installing the basic 2007.2 apps on the FSO baseline install.

In theory, it should be very simple, and should give us dialer, contact management, SMS, terminal, media player, gps app, etc. since all those already work on 2007.2. And the dialer should be stable, which it wasn't in 2007.2

First steps

The first pass at making the GTK software use the FSO will involve just creating a gsmd workalike that sends commands to the ophoned dbus api from FSO. mickeyterm is an example of another program that lets you send GSM commands through ophoned.

We want to have a build that is stable, so we'll need some standard way of identifying the latest stable pieces of all the different software in the SHR, as well as a way to identify previous released versions of the SHR.

Interest

See the Developer Info on the upper right side of the SHR project page.

How to join

  • Send a request to join on the SHR project on the OM projects page.
  • Join shr-devel@lists.projects.openmoko.org and send an introductory email. The introductory email can just be a couple of lines if you like. It should include what part would you want to work on, and any special knowledge you have that would relate to the project, e.g. if you are an OE guru or linux kernel geek, matchbox-window manager guru, etc.
  • Hang out in #openmoko-cdevel on irc.freenode.net between 5pm and 11pm GMT to chat with the people developing SHR. (Primarily MarcOChapeau and Ainulindale.)
  • See SHR Development to find out how to set up your development environment to work on existing SHR packages.

Tasks & status

The list of tasks is available at the SHR Milestone page. Some information is missing this is why the table below is still valid.

Task Status Owner Helping out Last update Comment
Run the build host Have server CPU time and disk space; just need to talk about git branches paulproteus 2008-07-03
Test & label good SHR releases Awaiting builds Kevin Dean Nobody 2008-07-05


Completed tasks:

Task Resolution When resolved
Set up launcher (home) page and document how to add new apps to it The launcher will be the apps tab of openmoko-today2 2008-07-08
Set up projects.openmoko.org project for the patch to apply to FSO to make it SHR Done! SHR Project HomePage 2008-07-08
fork media player for SHR Done! 2008-08-07

Statuses:

  • Needs owner! - someone needs to take responsibility for this task
  • Not started - someone has taken responsibility, but hasn't done anything yet...
  • Started - someone has started work, but there is nothing usable yet
  • Alpha - it might work, maybe
  • Beta - it probably works most of the time
  • Maintained - a stable release is out there, working on oddball bugs & new features
  • Done - a stable release is out there, no activity on this task now

Technical Help

Getting the source code

We're currently hosted by Ainulindale on svn://daria.forty-two.fr/shr as projects went down for a whole week-end.

There is no need to download the code independently as it is automatically obtained when setting the development environment described in SHR Development.

Build logic

Current applications (openmoko-dialer3 and openmoko-panel-gsm) use frameworkd. So in order to be able to build and test these applications, you have to build frameworkd (MS2) and gsm0710muxd.

libframeworkd-glib

In order to be able to use in an easy way frameworkd, without bothering about dbus calls (which could be difficult for new developers), we built a library allowing everyone to use the functions of frameworkd as if it were simple C functions. We're using asynchronous callbacks for dbus.

Architecture

SHR uses FSO to interface to the hardware, so see the FSO architecture documentation, too. For how the openmoko*3 applications that SHR forked off 2007.2 access FSO, see http://img117.imageshack.us/my.php?image=lfiv9.png

List of packages included

From FSO:

  • ophoned
  • preferencesd
  • pimd
  • odeviced
  • lots more...

From 2007.2:

  • TODO
  • lots more...

From ASU:

  • TODO
  • lots more...

IRC conversation about how we're using revision control

This is deprecated, for now we use shr-devel as our only repository. This will change after the first SHR release.
From 2007-07-07

12:36 < wurp2> Everything *new* goes on OM projects site
12:36 < Ainulindale> I totally agree
12:36 < wurp2> Updates to 2007.2 apps go back into the home svn
12:36 < Ainulindale> paulproteus: no, you're an external cabal all by yourself
                     :-)
12:36 < cb22> anyone planning on drawing up a roadmap?
12:36 < paulproteus> cb22, We can do that in Trac in fact.
12:36 < wurp2> And changes to the underlying release go as patches into our OE
               branch, yes?
12:36 < paulproteus> (or on the wiki page)
12:36 < paulproteus> wurp2, Right
12:36 < paulproteus> mwester, Sanity-check my terminology where I mess things
                     up!
12:37 < Ainulindale> hmmm fuzzy for me but what should go in OM and what should
                     go in OE ?
12:37 <@mwester> Sure
12:37 <@mwester> What do you mean by OM?
12:37 < paulproteus> Ainulindale, New software we write goes in the
                     projects.openmoko.org.
12:37 <@mwester> right.
12:37 < Ainulindale> Ok so the wrapper for example
12:37 < wurp2> Anything stand-alone goes in OM (projects.openmoko.org)
12:37 < wurp2> yeah
12:37 <@mwester> So we will use projects.openmoko.org for as much as we can,
                 and OE to build the distro.
12:37 < Ainulindale> Sounds right to me
12:37 < wurp2> Great!
12:38 <@mwester> We *will not* use the OM git repo, as that is owned and
                 controlled by Openmoko the company...

Reference Material

Personal tools

SHR is one of the many distributions that currently work on the Openmoko phones. You can compare a distribution with an Operating System on normal computers. It gives the phone all the software needed for operating. For more information about the different flavors, see distributions. Template:SHR

Overview

The Stable Hybrid Release (SHR) is intended to be a combination of the FSO, some of the Openmoko2007.2 GTK software, and the ASU that provides all of the functionality of the 2007.2 software, but with the stability of the FSO and the new GUI toolkits provided by the ASU. It will probably be based on an ASU build, with the FSO software and GTK end-user apps added.

(We're not married to the idea of using the GTK apps, but they already exist and are more-or-less debugged at least on the UI side. If someone knows of a more stable and/or usable app that's appropriate for the OM, let us know by dropping a comment on the discussion tab of this page.)

Follow the project here: SHR Project Homepage

Why SHR exists

This is long and rambling, and maybe more of a tirade than information, but it does give some background on why this project was started. The overview gives, well, the overview, this is more of a deeper examination of the existing releases and why we felt we needed something new.

Feel free to skip this whole section if you already think SHR is a good idea :-)

Why not ASU?

ASU is the distro that OM is putting their main effort into right now. ASU looks very slick, but is very unstable right now, and is likely to be unstable and feature-poor for some time.

Why not 2007.2?

2007.2 is the "old" Openmoko distribution, now unsupported. Unsupported == often broken. Also, neither calls nor suspend/resume ever worked reliably.

Why not Qtopia?

You can also install Qtopia on the phone.

Qtopia is stable but you can only build qt apps on Qtopia, which means lots of linux apps you might want to port suddenly got a lot harder to port. And some people just don't like developing for qt.

Also, as far as I know, there is no documented build procedure for Qtopia on Openmoko.

Why not FSO?

FSO is the initiative by Mickey Lauer and crew to create a good D-Bus infrastructure which runs on the neos, among other devices.

FSO is by far the most stable & usable release, if all you want is a phone. (I mean *all*. It just has a dialer right now, not even call history.)

FSO is never intended on its own to be a full image, it's just the infrastructure and a demo app.

Other people are supposed to put a front end on FSO. So that's what we're doing.

Why SHR?

So SHR is FSO, with us doing the necessary work to port the old high-functionality 2007.2 stuff on a stable call platform. We have an adapter from the 2007.2 call service to the FSO call service and we're installing the basic 2007.2 apps on the FSO baseline install.

In theory, it should be very simple, and should give us dialer, contact management, SMS, terminal, media player, gps app, etc. since all those already work on 2007.2. And the dialer should be stable, which it wasn't in 2007.2

First steps

The first pass at making the GTK software use the FSO will involve just creating a gsmd workalike that sends commands to the ophoned dbus api from FSO. mickeyterm is an example of another program that lets you send GSM commands through ophoned.

We want to have a build that is stable, so we'll need some standard way of identifying the latest stable pieces of all the different software in the SHR, as well as a way to identify previous released versions of the SHR.

Interest

See the Developer Info on the upper right side of the SHR project page.

How to join

  • Send a request to join on the SHR project on the OM projects page.
  • Join shr-devel@lists.projects.openmoko.org and send an introductory email. The introductory email can just be a couple of lines if you like. It should include what part would you want to work on, and any special knowledge you have that would relate to the project, e.g. if you are an OE guru or linux kernel geek, matchbox-window manager guru, etc.
  • Hang out in #openmoko-cdevel on irc.freenode.net between 5pm and 11pm GMT to chat with the people developing SHR. (Primarily MarcOChapeau and Ainulindale.)
  • See SHR Development to find out how to set up your development environment to work on existing SHR packages.

Tasks & status

The list of tasks is available at the SHR Milestone page. Some information is missing this is why the table below is still valid.

Task Status Owner Helping out Last update Comment
Run the build host Have server CPU time and disk space; just need to talk about git branches paulproteus 2008-07-03
Test & label good SHR releases Awaiting builds Kevin Dean Nobody 2008-07-05


Completed tasks:

Task Resolution When resolved
Set up launcher (home) page and document how to add new apps to it The launcher will be the apps tab of openmoko-today2 2008-07-08
Set up projects.openmoko.org project for the patch to apply to FSO to make it SHR Done! SHR Project HomePage 2008-07-08
fork media player for SHR Done! 2008-08-07

Statuses:

  • Needs owner! - someone needs to take responsibility for this task
  • Not started - someone has taken responsibility, but hasn't done anything yet...
  • Started - someone has started work, but there is nothing usable yet
  • Alpha - it might work, maybe
  • Beta - it probably works most of the time
  • Maintained - a stable release is out there, working on oddball bugs & new features
  • Done - a stable release is out there, no activity on this task now

Technical Help

Getting the source code

We're currently hosted by Ainulindale on svn://daria.forty-two.fr/shr as projects went down for a whole week-end.

There is no need to download the code independently as it is automatically obtained when setting the development environment described in SHR Development.

Build logic

Current applications (openmoko-dialer3 and openmoko-panel-gsm) use frameworkd. So in order to be able to build and test these applications, you have to build frameworkd (MS2) and gsm0710muxd.

libframeworkd-glib

In order to be able to use in an easy way frameworkd, without bothering about dbus calls (which could be difficult for new developers), we built a library allowing everyone to use the functions of frameworkd as if it were simple C functions. We're using asynchronous callbacks for dbus.

Architecture

SHR uses FSO to interface to the hardware, so see the FSO architecture documentation, too. For how the openmoko*3 applications that SHR forked off 2007.2 access FSO, see http://img117.imageshack.us/my.php?image=lfiv9.png

List of packages included

From FSO:

  • ophoned
  • preferencesd
  • pimd
  • odeviced
  • lots more...

From 2007.2:

  • TODO
  • lots more...

From ASU:

  • TODO
  • lots more...

IRC conversation about how we're using revision control

This is deprecated, for now we use shr-devel as our only repository. This will change after the first SHR release.
From 2007-07-07

12:36 < wurp2> Everything *new* goes on OM projects site
12:36 < Ainulindale> I totally agree
12:36 < wurp2> Updates to 2007.2 apps go back into the home svn
12:36 < Ainulindale> paulproteus: no, you're an external cabal all by yourself
                     :-)
12:36 < cb22> anyone planning on drawing up a roadmap?
12:36 < paulproteus> cb22, We can do that in Trac in fact.
12:36 < wurp2> And changes to the underlying release go as patches into our OE
               branch, yes?
12:36 < paulproteus> (or on the wiki page)
12:36 < paulproteus> wurp2, Right
12:36 < paulproteus> mwester, Sanity-check my terminology where I mess things
                     up!
12:37 < Ainulindale> hmmm fuzzy for me but what should go in OM and what should
                     go in OE ?
12:37 <@mwester> Sure
12:37 <@mwester> What do you mean by OM?
12:37 < paulproteus> Ainulindale, New software we write goes in the
                     projects.openmoko.org.
12:37 <@mwester> right.
12:37 < Ainulindale> Ok so the wrapper for example
12:37 < wurp2> Anything stand-alone goes in OM (projects.openmoko.org)
12:37 < wurp2> yeah
12:37 <@mwester> So we will use projects.openmoko.org for as much as we can,
                 and OE to build the distro.
12:37 < Ainulindale> Sounds right to me
12:37 < wurp2> Great!
12:38 <@mwester> We *will not* use the OM git repo, as that is owned and
                 controlled by Openmoko the company...

Reference Material