Talk:SHR Party Page

From Openmoko

Revision as of 20:56, 9 March 2010 by Rakshat (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

1. What is SHR?

2. Can you tell a bit about the history of SHR? Why was the development of SHR started? What were the aims and objectives?

3. What are the target platforms for SHR? Does SHR target only Openmoko phones or is it designed as a generic mobile communication/ PDA solution?

4. How does the development process of SHR work ( As in who/ who all decide what is to be doe at what priority)?

5. Who are the main developers working on SHR? What are their areas of interest wrt SHR and what are they working on these days?

6. How far has the development of SHR progressed? Is the current SHR image usable out of the box?

7. Can you explain the structure of SHR (as in kernel, middleawre windows manager, data storage structure, application layer etc)?

8. If a S/W developer wishes to contribute to SHR what should she/ he do? Does she/ he need to have any specific skill sets to contribute to SHR?

9. How does a developer make sure her/ his application runs on SHR. Is there any centralised verification process or a repository where verified applications are stored?

10. Can you list the main areas where you would appreciate help in the SHR development process and are looking for volunteers.

11. What is the relationship of SHR with FSO ( A bit about FSO too). Is SHR an user interface on top of FSO or does it offer something more?

12. Can someone highlight the Short term, medium term and long term benefits of using SHR to Hardware hackers and hardware manufacturers?

13. What milestones does SHR hope to hit in 2010?

13. Where do I find all the code and documentation for SHR?

14. When will SHR/ Stable be available :)

ANSWERS

Martin.Jansa@gmail.com

4. How does the development process of SHR work ( As in who/ who all decide > what is to be doe at what priority)?


Every developer does what he likes/needs the most, when there is some controversial change then we usually discuss it before on

  1. openmoko-cdevel.


> 6. How far has the development of SHR progressed? Is the current SHR image > usable out of the box?


That's questions more for our users, but AFAIK all devs are able to use images on daily basis and I think it's usually usable out of the box. But of course there is some breakage from time to time, because it's really living development and almost no testing before building stuff in shr-u (that's why shr-t exists)


> 8. If a S/W developer wishes to contribute to SHR what should she/ he do? > Does she/ he need to have any specific skill sets to contribute to SHR?


Personally I think that best start is to build own images http://wiki.shr-project.org/trac/wiki/Building%20SHR and then start improving any aplication you like or just improving recipes which helps a lot too.

Normal linux hacker skills like C/python/shell knowledge are usefull for fixing build failures, creating patches.


> 9. How does a developer make sure her/ his application runs on SHR. Is there > any centralised verification process or a repository where verified > applications are stored?


I don't know about any verification and IMHO it doesn't make much sense when distro is moving fast (ie EFL libs are upgraded often, fso, phoneuid, phonefsod is developing fast), so even verified app is not quaranteed to run a month later.

And keep backward compatibility in this state is non'sense (as our upstream also doesn't guaranetee compatibility - yet).

> 10. Can you list the main areas where you would appreciate help in the

> SHRdevelopment process and are looking for volunteers.

> > 11. What is the relationship of SHR with FSO ( A bit about FSO too).

> Is SHRan user interface on top of

> FSO or does it offer something more?


FSO is whole middleware, SHR consists of UI on top of FSO and also bundles it with other usefull applications to easy flashable images.


> 12. Can someone highlight the Short term, medium term and long term benefits > of using SHR to Hardware hackers and hardware manufacturers? > > 13. What milestones does SHR hope to hit in 2010?


Hi hope to see 2.6.32 kernel used by default as it will make next upgrades to 2.6.33 and newer version much more easily and thanks to great work of Lars-Peter Clausen, Thomas White and other kernel hackers is as usable as 2.6.29-rc3 was and much better shape.


> 13. Where do I find all the code and documentation for SHR?


Build metadata http://git.openembedded.org/ Apps sources http://git.shr-project.org/git/ FSO sources http://git.freesmartphone.org/ And other stuff (urls defined in build metadata - recipe files).


> 14. When will SHR/ Stable be available :)


No idea, I don't think we should hurry with that. Even with shr-testing I see the case when users are expecting new stuff which happens only in shr-unstable to be available in shr-testing soon.

If there is shr-stable I guess it will be just released and then no more upgrades to it, so from user POV I don't see any advantage over shr-testing.



Sebastian Krzyszkowiak

> 1. What is SHR?


SHR is a embedded distribution aimed to give users power of free software in their smartphones. It's based on OpenEmbedded build system and on FSO phone stack, which is the best approach to smartphone middleware for us (well, at least in my opinion).


> 2. Can you tell a bit about the history of SHR? Why was the development of > SHR started? What were the aims and objectives?


I joined SHR development a bit later, but AFAIK SHR was created after announcement of ASU (later called Om2008) and its first goal was to port 2007.2 applications to FSO stack and to use them in ASU environment (that's why it's called Stable *Hybrid* Release).


> 3. What are the target platforms for SHR? Does SHR target only Openmoko > phones or is it designed as a generic mobile communication/ PDA solution?


ATM we target only Openmoko phones, but only because they are the most open and most of us have them. We're keeping our eyes on effort to port FSO to HTC phones, Palm Pre and other devices and we're also interested in running SHR on them. So our aim is to be generic smartphone operating system and to run wherever FSO runs.


> 4. How does the development process of SHR work ( As in who/ who all decide > what is to be doe at what priority)?


We try to always look on what community wants and to not decide anything important without community acceptance. For organizational reasons, there is SHR core team, which consists of the most active SHR and FSO developers. Members of coreteam should be listed somewhere on wiki, I won't write it now because I don't want to skip anyone :)


> 5. Who are the main developers working on SHR? What are their areas of > interest wrt SHR and what are they working on these days?


I think TAsn and mrmoku (working mostly on libphone* libs, but not only) and JaMa (OpenEmbedded) are the most active developers ATM. Also, spaetz is maitaining shr-testing OE branch. I used to work on shr-settings, shr-installer, opimd and few others - but recently I didn't have time to do active development, so I don't know if I'm the most active anymore :) Also, there are some people who are sending to us patches to shr-devel maillist.


> 6. How far has the development of SHR progressed? Is the current SHR image > usable out of the box?


It depends, but mostly - yes. Most of us is using their SHR based Freerunners as primary, daily phones (me too).


> 7. Can you explain the structure of SHR (as in kernel, middleawre windows > manager, data storage structure, application layer etc)?


Kernel - Linux. Actually 2.6.29, but we're looking forward newer kernels (SHR supports them, but not out-of-box) As window manager we're using Enlightenment with Illume module (but there started first efforts to drop Illume and replace it with Illume2). Middleware is obvious - freesmartphone.org :) As data storage we're using one of FSO daemons - opimd. About applications - they are different. Some of them comes from GPE project, some of them were written by Openmoko community, and some of them were written by us for us ;)

About architecture of SHR apps and libs - I think TAsn and mrmoku are the ones who should talk about it :)


> 8. If a S/W developer wishes to contribute to SHR what should she/ he do? > Does she/ he need to have any specific skill sets to contribute to SHR?


Of course no! There are many different ways users can contribute to SHR - code, API organization, distro mainternance, artwork, themes... We have running patchwork system on our shr-devel maillist, so patches are welcome and they won't be forgotten. Also, developers can just hang on IRC - #openmoko-cdevel channel on freenode - in order to talk about what they can do. Obtaining commit access to our git repos is easy, just send few patches, be active - and then, when you'll ask for access, you'll get it :)


> 9. How does a developer make sure her/ his application runs on SHR. Is there > any centralised verification process or a repository where verified > applications are stored?


Just send us one file - it's called "bitbake recipe" and has *.bb extension. More about writing them you can read on OpenEmbedded websites. After sending us this file, your app will be integrated in our main repositiories and we will have to keep eye on package - if it works, builds etc. - not app developer (and personally: that's why I don't like opkg.org :P)


> 10. Can you list the main areas where you would appreciate help in the SHR > development process and are looking for volunteers.


SHR testing and SHR stable maintainers with skills in OpenEmbedded. Also, some new themes would be welcomed :)


> 11. What is the relationship of SHR with FSO ( A bit about FSO too). Is SHR > an user interface on top of FSO or does it offer something more?


SHR is both user interface on top of FSO, and OE based distribution containing FSO, SHR apps and some other utilities.


> 12. Can someone highlight the Short term, medium term and long term benefits > of using SHR to Hardware hackers and hardware manufacturers?


For hardware hackers: it gives you a full access to hardware. It's unlocked, full Linux, like on PC.


> 13. What milestones does SHR hope to hit in 2010?


I think SHR stable release. Also, we look forward to improvements in opimd done by TAsn and polishing user interface of phone apps.


> 13. Where do I find all the code and documentation for SHR?


http://git.shr-project.org/


> 14. When will SHR/ Stable be available :)


When it'll be ready :)

(I know I didn't answer exhaustive to all questions, but I hope answers from others will be complementary to mine ;))

Regards!


> > 1. What is SHR? SHR is the abbreviation for 'Stable Hybrid Release', which comes from its origins. In the beginning of OpenMoko there was a GTK based distro, which then got replaced by an EFL based one. SHR was trying to combine both worlds. That's where the 'Hybrid' comes from - at least that's what I remember :)

> > > > 2. Can you tell a bit about the history of SHR? Why was the development > > of SHR started? What were the aims and objectives? See 1. It was started because existing distros for the OpenMoko phones did suck (and at that time there were not that plenty as today). The other objective was to have a community based distro, which fullfills the needs of the community and not of some company.

> > > > 3. What are the target platforms for SHR? Does SHR target only > > Openmokophones or is it designed as a generic mobile communication/ > > PDA solution? SHR started as a Distro for the OpenMoko phones. We would really like to see it (and I'm convinced we *will* see it) running on other devices too. Next most probable candidates are the Palm Pre and the HTC Dream.

> > > > 4. How does the development process of SHR work ( As in who/ who all > > decide what is to be doe at what priority)? > > Every developer does what he likes/needs the most, when there is some > controversial change then we usually discuss it before on > #openmoko-cdevel. > > > 5. Who are the main developers working on SHR? What are their areas of > > interest wrt SHR and what are they working on these days? > > Most patches in last few months flow from: > mrmoku - Klaus Kurzmann > - whole SHR telephony stack > TAsn - Tom Hacohen > - whole SHR telephony stack > spaetz - Sebastian Spaeth > - whole SHR telephony stack, shr-testing maintainer > dos - Sebastian Krzyszkowiak > - whole SHR telephony stack, themes, enlightenment stuff > JaMa - Martin Jansa > - build metadata > Heinervdm - Thomas Zimmermann > - build metadata > > but also lots of developers working on stuff which makes SHR better > all OE devs > - build metadata > Michael 'Mickey' Lauer > - incredible work on FSO > Lars-Peter Clausen > - guru for new kernel version > Thomas White > - guru for new DRM driver > Jesus McCloud > - great themes > Other 3rd party app developers > - great apps :) > > I hope I didn't forget someone > > > 6. How far has the development of SHR progressed? Is the current SHR > > image usable out of the box? > > That's questions more for our users, but AFAIK all devs are able to use > images on daily basis and I think it's usually usable out of the box. > But of course there is some breakage from time to time, because it's > really living development and almost no testing before building stuff > in shr-u (that's why shr-t exists) > > > 7. Can you explain the structure of SHR (as in kernel, middleawre windows > > manager, data storage structure, application layer etc)? SHR is based on a linux kernel, FSO as middleware and Enlightenement/Illume as window manager. On top of that we have our telephony stack consisting of the following two parts: - phonefsod: a system daemon interacting with the FSO middleware, eg. reacting to incoming phone calls - phoneuid: a GUI daemon implementing the user interface, eg. the dialer screen

> > > > 8. If a S/W developer wishes to contribute to SHR what should she/ he do? > > Does she/ he need to have any specific skill sets to contribute to SHR? > > Personally I think that best start is to build own images > http://wiki.shr-project.org/trac/wiki/Building%20SHR > and then start improving any aplication you like or just improving > recipes which helps a lot too. > > Normal linux hacker skills like C/python/shell knowledge are usefull for > fixing build failures, creating patches. > > > 9. How does a developer make sure her/ his application runs on SHR. Is > > there any centralised verification process or a repository where > > verified applications are stored? > > I don't know about any verification and IMHO it doesn't make much sense > when distro is moving fast (ie EFL libs are upgraded often, fso, > phoneuid, phonefsod is developing fast), so even verified app is not > quaranteed to run a month later. > > And keep backward compatibility in this state is non'sense (as our > upstream also doesn't guaranetee compatibility - yet). > > > 10. Can you list the main areas where you would appreciate help in the > > SHRdevelopment process and are looking for volunteers. One thing we would need very much is a maintainer for SHR stable. Other than that any help is of course appreciated :-)

> > > > 11. What is the relationship of SHR with FSO ( A bit about FSO too). > > Is SHRan user interface on top of > > FSO or does it offer something more? > > FSO is whole middleware, SHR consists of UI on top of FSO and also > bundles it with other usefull applications to easy flashable images. > > > 12. Can someone highlight the Short term, medium term and long term > > benefits of using SHR to Hardware hackers and hardware manufacturers? The immediate benefit for Hardware hackers probably is the openess - having a standard Linux system without black holes (with the obvious exception of some parts as the GSM firmware). For Hardware manufacturers I don't know. Maybe a benefit _could_ be to get the software for 'free'. I doubt they are interested in that though :/

> > > > 13. What milestones does SHR hope to hit in 2010? > > Hi hope to see 2.6.32 kernel used by default as it will make next > upgrades to 2.6.33 and newer version much more easily and thanks to > great work of Lars-Peter Clausen, Thomas White and other kernel hackers > is as usable as 2.6.29-rc3 was and much better shape. In addition I hope to see it running on other devices such as the Palm Pre or the HTC Dream. > > > 13. Where do I find all the code and documentation for SHR? > > Build metadata > http://git.openembedded.org/ > Apps sources > http://git.shr-project.org/git/ > FSO sources > http://git.freesmartphone.org/ > And other stuff (urls defined in build metadata - recipe files). User manual http://wiki.openmoko.org/wiki/SHR_User_Manual

> > > 14. When will SHR/ Stable be available :) > > No idea, I don't think we should hurry with that. Even with shr-testing > I see the case when users are expecting new stuff which happens only in > shr-unstable to be available in shr-testing soon. > > If there is shr-stable I guess it will be just released and then no more > upgrades to it, so from user POV I don't see any advantage over > shr-testing. yes, I completely agree with Martin. There is too much stuff missing so that users always will want to have new stuff merged into it. We were talking about renaming the current SHR-Testing to SHR-Stable, when the new SHR-Testing is ready. Personally I think that would just be stable in the sense of not getting updates - and not in the sense of having a complete, stable phone ;)

BUT, stuff is progressing fast these days. FSO2 (the vala-rewrite of FSO) is not missing much (many thanks to Mickey Lauer for that - he's doing that incredible work almost alone). And our phone stack is progressing too. I would not be surprised if we reach something I would call a good and stable phone distro before this year ends :-)

Regards -- Klaus 'mrmoku' Kurzmann

Personal tools

1. What is SHR?

2. Can you tell a bit about the history of SHR? Why was the development of SHR started? What were the aims and objectives?

3. What are the target platforms for SHR? Does SHR target only Openmoko phones or is it designed as a generic mobile communication/ PDA solution?

4. How does the development process of SHR work ( As in who/ who all decide what is to be doe at what priority)?

5. Who are the main developers working on SHR? What are their areas of interest wrt SHR and what are they working on these days?

6. How far has the development of SHR progressed? Is the current SHR image usable out of the box?

7. Can you explain the structure of SHR (as in kernel, middleawre windows manager, data storage structure, application layer etc)?

8. If a S/W developer wishes to contribute to SHR what should she/ he do? Does she/ he need to have any specific skill sets to contribute to SHR?

9. How does a developer make sure her/ his application runs on SHR. Is there any centralised verification process or a repository where verified applications are stored?

10. Can you list the main areas where you would appreciate help in the SHR development process and are looking for volunteers.

11. What is the relationship of SHR with FSO ( A bit about FSO too). Is SHR an user interface on top of FSO or does it offer something more?

12. Can someone highlight the Short term, medium term and long term benefits of using SHR to Hardware hackers and hardware manufacturers?

13. What milestones does SHR hope to hit in 2010?

13. Where do I find all the code and documentation for SHR?

14. When will SHR/ Stable be available :)

ANSWERS

Martin.Jansa@gmail.com

4. How does the development process of SHR work ( As in who/ who all decide > what is to be doe at what priority)?


Every developer does what he likes/needs the most, when there is some controversial change then we usually discuss it before on

  1. openmoko-cdevel.


> 6. How far has the development of SHR progressed? Is the current SHR image > usable out of the box?


That's questions more for our users, but AFAIK all devs are able to use images on daily basis and I think it's usually usable out of the box. But of course there is some breakage from time to time, because it's really living development and almost no testing before building stuff in shr-u (that's why shr-t exists)


> 8. If a S/W developer wishes to contribute to SHR what should she/ he do? > Does she/ he need to have any specific skill sets to contribute to SHR?


Personally I think that best start is to build own images http://wiki.shr-project.org/trac/wiki/Building%20SHR and then start improving any aplication you like or just improving recipes which helps a lot too.

Normal linux hacker skills like C/python/shell knowledge are usefull for fixing build failures, creating patches.


> 9. How does a developer make sure her/ his application runs on SHR. Is there > any centralised verification process or a repository where verified > applications are stored?


I don't know about any verification and IMHO it doesn't make much sense when distro is moving fast (ie EFL libs are upgraded often, fso, phoneuid, phonefsod is developing fast), so even verified app is not quaranteed to run a month later.

And keep backward compatibility in this state is non'sense (as our upstream also doesn't guaranetee compatibility - yet).

> 10. Can you list the main areas where you would appreciate help in the

> SHRdevelopment process and are looking for volunteers.

> > 11. What is the relationship of SHR with FSO ( A bit about FSO too).

> Is SHRan user interface on top of

> FSO or does it offer something more?


FSO is whole middleware, SHR consists of UI on top of FSO and also bundles it with other usefull applications to easy flashable images.


> 12. Can someone highlight the Short term, medium term and long term benefits > of using SHR to Hardware hackers and hardware manufacturers? > > 13. What milestones does SHR hope to hit in 2010?


Hi hope to see 2.6.32 kernel used by default as it will make next upgrades to 2.6.33 and newer version much more easily and thanks to great work of Lars-Peter Clausen, Thomas White and other kernel hackers is as usable as 2.6.29-rc3 was and much better shape.


> 13. Where do I find all the code and documentation for SHR?


Build metadata http://git.openembedded.org/ Apps sources http://git.shr-project.org/git/ FSO sources http://git.freesmartphone.org/ And other stuff (urls defined in build metadata - recipe files).


> 14. When will SHR/ Stable be available :)


No idea, I don't think we should hurry with that. Even with shr-testing I see the case when users are expecting new stuff which happens only in shr-unstable to be available in shr-testing soon.

If there is shr-stable I guess it will be just released and then no more upgrades to it, so from user POV I don't see any advantage over shr-testing.



Sebastian Krzyszkowiak

> 1. What is SHR?


SHR is a embedded distribution aimed to give users power of free software in their smartphones. It's based on OpenEmbedded build system and on FSO phone stack, which is the best approach to smartphone middleware for us (well, at least in my opinion).


> 2. Can you tell a bit about the history of SHR? Why was the development of > SHR started? What were the aims and objectives?


I joined SHR development a bit later, but AFAIK SHR was created after announcement of ASU (later called Om2008) and its first goal was to port 2007.2 applications to FSO stack and to use them in ASU environment (that's why it's called Stable *Hybrid* Release).


> 3. What are the target platforms for SHR? Does SHR target only Openmoko > phones or is it designed as a generic mobile communication/ PDA solution?


ATM we target only Openmoko phones, but only because they are the most open and most of us have them. We're keeping our eyes on effort to port FSO to HTC phones, Palm Pre and other devices and we're also interested in running SHR on them. So our aim is to be generic smartphone operating system and to run wherever FSO runs.


> 4. How does the development process of SHR work ( As in who/ who all decide > what is to be doe at what priority)?


We try to always look on what community wants and to not decide anything important without community acceptance. For organizational reasons, there is SHR core team, which consists of the most active SHR and FSO developers. Members of coreteam should be listed somewhere on wiki, I won't write it now because I don't want to skip anyone :)


> 5. Who are the main developers working on SHR? What are their areas of > interest wrt SHR and what are they working on these days?


I think TAsn and mrmoku (working mostly on libphone* libs, but not only) and JaMa (OpenEmbedded) are the most active developers ATM. Also, spaetz is maitaining shr-testing OE branch. I used to work on shr-settings, shr-installer, opimd and few others - but recently I didn't have time to do active development, so I don't know if I'm the most active anymore :) Also, there are some people who are sending to us patches to shr-devel maillist.


> 6. How far has the development of SHR progressed? Is the current SHR image > usable out of the box?


It depends, but mostly - yes. Most of us is using their SHR based Freerunners as primary, daily phones (me too).


> 7. Can you explain the structure of SHR (as in kernel, middleawre windows > manager, data storage structure, application layer etc)?


Kernel - Linux. Actually 2.6.29, but we're looking forward newer kernels (SHR supports them, but not out-of-box) As window manager we're using Enlightenment with Illume module (but there started first efforts to drop Illume and replace it with Illume2). Middleware is obvious - freesmartphone.org :) As data storage we're using one of FSO daemons - opimd. About applications - they are different. Some of them comes from GPE project, some of them were written by Openmoko community, and some of them were written by us for us ;)

About architecture of SHR apps and libs - I think TAsn and mrmoku are the ones who should talk about it :)


> 8. If a S/W developer wishes to contribute to SHR what should she/ he do? > Does she/ he need to have any specific skill sets to contribute to SHR?


Of course no! There are many different ways users can contribute to SHR - code, API organization, distro mainternance, artwork, themes... We have running patchwork system on our shr-devel maillist, so patches are welcome and they won't be forgotten. Also, developers can just hang on IRC - #openmoko-cdevel channel on freenode - in order to talk about what they can do. Obtaining commit access to our git repos is easy, just send few patches, be active - and then, when you'll ask for access, you'll get it :)


> 9. How does a developer make sure her/ his application runs on SHR. Is there > any centralised verification process or a repository where verified > applications are stored?


Just send us one file - it's called "bitbake recipe" and has *.bb extension. More about writing them you can read on OpenEmbedded websites. After sending us this file, your app will be integrated in our main repositiories and we will have to keep eye on package - if it works, builds etc. - not app developer (and personally: that's why I don't like opkg.org :P)


> 10. Can you list the main areas where you would appreciate help in the SHR > development process and are looking for volunteers.


SHR testing and SHR stable maintainers with skills in OpenEmbedded. Also, some new themes would be welcomed :)


> 11. What is the relationship of SHR with FSO ( A bit about FSO too). Is SHR > an user interface on top of FSO or does it offer something more?


SHR is both user interface on top of FSO, and OE based distribution containing FSO, SHR apps and some other utilities.


> 12. Can someone highlight the Short term, medium term and long term benefits > of using SHR to Hardware hackers and hardware manufacturers?


For hardware hackers: it gives you a full access to hardware. It's unlocked, full Linux, like on PC.


> 13. What milestones does SHR hope to hit in 2010?


I think SHR stable release. Also, we look forward to improvements in opimd done by TAsn and polishing user interface of phone apps.


> 13. Where do I find all the code and documentation for SHR?


http://git.shr-project.org/


> 14. When will SHR/ Stable be available :)


When it'll be ready :)

(I know I didn't answer exhaustive to all questions, but I hope answers from others will be complementary to mine ;))

Regards!


> > 1. What is SHR? SHR is the abbreviation for 'Stable Hybrid Release', which comes from its origins. In the beginning of OpenMoko there was a GTK based distro, which then got replaced by an EFL based one. SHR was trying to combine both worlds. That's where the 'Hybrid' comes from - at least that's what I remember :)

> > > > 2. Can you tell a bit about the history of SHR? Why was the development > > of SHR started? What were the aims and objectives? See 1. It was started because existing distros for the OpenMoko phones did suck (and at that time there were not that plenty as today). The other objective was to have a community based distro, which fullfills the needs of the community and not of some company.

> > > > 3. What are the target platforms for SHR? Does SHR target only > > Openmokophones or is it designed as a generic mobile communication/ > > PDA solution? SHR started as a Distro for the OpenMoko phones. We would really like to see it (and I'm convinced we *will* see it) running on other devices too. Next most probable candidates are the Palm Pre and the HTC Dream.

> > > > 4. How does the development process of SHR work ( As in who/ who all > > decide what is to be doe at what priority)? > > Every developer does what he likes/needs the most, when there is some > controversial change then we usually discuss it before on > #openmoko-cdevel. > > > 5. Who are the main developers working on SHR? What are their areas of > > interest wrt SHR and what are they working on these days? > > Most patches in last few months flow from: > mrmoku - Klaus Kurzmann > - whole SHR telephony stack > TAsn - Tom Hacohen > - whole SHR telephony stack > spaetz - Sebastian Spaeth > - whole SHR telephony stack, shr-testing maintainer > dos - Sebastian Krzyszkowiak > - whole SHR telephony stack, themes, enlightenment stuff > JaMa - Martin Jansa > - build metadata > Heinervdm - Thomas Zimmermann > - build metadata > > but also lots of developers working on stuff which makes SHR better > all OE devs > - build metadata > Michael 'Mickey' Lauer > - incredible work on FSO > Lars-Peter Clausen > - guru for new kernel version > Thomas White > - guru for new DRM driver > Jesus McCloud > - great themes > Other 3rd party app developers > - great apps :) > > I hope I didn't forget someone > > > 6. How far has the development of SHR progressed? Is the current SHR > > image usable out of the box? > > That's questions more for our users, but AFAIK all devs are able to use > images on daily basis and I think it's usually usable out of the box. > But of course there is some breakage from time to time, because it's > really living development and almost no testing before building stuff > in shr-u (that's why shr-t exists) > > > 7. Can you explain the structure of SHR (as in kernel, middleawre windows > > manager, data storage structure, application layer etc)? SHR is based on a linux kernel, FSO as middleware and Enlightenement/Illume as window manager. On top of that we have our telephony stack consisting of the following two parts: - phonefsod: a system daemon interacting with the FSO middleware, eg. reacting to incoming phone calls - phoneuid: a GUI daemon implementing the user interface, eg. the dialer screen

> > > > 8. If a S/W developer wishes to contribute to SHR what should she/ he do? > > Does she/ he need to have any specific skill sets to contribute to SHR? > > Personally I think that best start is to build own images > http://wiki.shr-project.org/trac/wiki/Building%20SHR > and then start improving any aplication you like or just improving > recipes which helps a lot too. > > Normal linux hacker skills like C/python/shell knowledge are usefull for > fixing build failures, creating patches. > > > 9. How does a developer make sure her/ his application runs on SHR. Is > > there any centralised verification process or a repository where > > verified applications are stored? > > I don't know about any verification and IMHO it doesn't make much sense > when distro is moving fast (ie EFL libs are upgraded often, fso, > phoneuid, phonefsod is developing fast), so even verified app is not > quaranteed to run a month later. > > And keep backward compatibility in this state is non'sense (as our > upstream also doesn't guaranetee compatibility - yet). > > > 10. Can you list the main areas where you would appreciate help in the > > SHRdevelopment process and are looking for volunteers. One thing we would need very much is a maintainer for SHR stable. Other than that any help is of course appreciated :-)

> > > > 11. What is the relationship of SHR with FSO ( A bit about FSO too). > > Is SHRan user interface on top of > > FSO or does it offer something more? > > FSO is whole middleware, SHR consists of UI on top of FSO and also > bundles it with other usefull applications to easy flashable images. > > > 12. Can someone highlight the Short term, medium term and long term > > benefits of using SHR to Hardware hackers and hardware manufacturers? The immediate benefit for Hardware hackers probably is the openess - having a standard Linux system without black holes (with the obvious exception of some parts as the GSM firmware). For Hardware manufacturers I don't know. Maybe a benefit _could_ be to get the software for 'free'. I doubt they are interested in that though :/

> > > > 13. What milestones does SHR hope to hit in 2010? > > Hi hope to see 2.6.32 kernel used by default as it will make next > upgrades to 2.6.33 and newer version much more easily and thanks to > great work of Lars-Peter Clausen, Thomas White and other kernel hackers > is as usable as 2.6.29-rc3 was and much better shape. In addition I hope to see it running on other devices such as the Palm Pre or the HTC Dream. > > > 13. Where do I find all the code and documentation for SHR? > > Build metadata > http://git.openembedded.org/ > Apps sources > http://git.shr-project.org/git/ > FSO sources > http://git.freesmartphone.org/ > And other stuff (urls defined in build metadata - recipe files). User manual http://wiki.openmoko.org/wiki/SHR_User_Manual

> > > 14. When will SHR/ Stable be available :) > > No idea, I don't think we should hurry with that. Even with shr-testing > I see the case when users are expecting new stuff which happens only in > shr-unstable to be available in shr-testing soon. > > If there is shr-stable I guess it will be just released and then no more > upgrades to it, so from user POV I don't see any advantage over > shr-testing. yes, I completely agree with Martin. There is too much stuff missing so that users always will want to have new stuff merged into it. We were talking about renaming the current SHR-Testing to SHR-Stable, when the new SHR-Testing is ready. Personally I think that would just be stable in the sense of not getting updates - and not in the sense of having a complete, stable phone ;)

BUT, stuff is progressing fast these days. FSO2 (the vala-rewrite of FSO) is not missing much (many thanks to Mickey Lauer for that - he's doing that incredible work almost alone). And our phone stack is progressing too. I would not be surprised if we reach something I would call a good and stable phone distro before this year ends :-)

Regards -- Klaus 'mrmoku' Kurzmann