Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
On 15/08/08 15:20:53, Benito Torres wrote: On the cpu-hogging: playing mp3s takes constantly ~30% (with and without pulseaudio). But mplayer also uses 25%, while in OM2007.2 it was around 10%. So maybe this is not a mediaplayer-issue but one of the sound-subsystem? In FSO just go into the terminal and do modprobe snd-pcm-oss and MPlayer will use less cpu. Michael. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
The package I'm using (and dependency packages) is now up at http://hedora.ath.cx/moko/ Let me know if you hit any problems. -Rusty Russell Sears wrote: There are a bunch of manual steps right now: - openmoko-mediaplayer is hardcoded to use pulseaudio. Switching to alsa is a one-line change. - the mediaplayer theme files need to live in the Raleigh directory not in Moko - There's some dependency on a openmoko sound system. I don't know what it does, or if it's needed. - I pulled packages out of my mokomakefile, and installed them using opkg - there are lots of pulseaudio dependencies to be removed, so I used opkg --force-depends to install the mediaplayer package. Some of the packages may be unnecessary / cause breakage. My home server is down at the moment, so I don't have anywhere to stick the modified binary... I'll figure out what's going on with it and post better directions and the binary tonight. -Rusty Benito wrote: On Thu, Aug 14, 2008 at 10:08 (-0700), Russell Sears wrote: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Would you provide that to us? I'd like to use it, too. Thx, /Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
Michael 'Mickey' Lauer wrote: Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Cool. Headphone insertion isn't detected yet, but it does mute/stop the music when you pick up the phone). Please add a ticket. Where? I just added a bunch of FSO tickets to http://docs.openmoko.org/trac/; which has an FSO option in the milestone pulldown menu. Then I found trac.freesmartphone.org Now I just need music and tangogps to work at the same time. The framework gps thing is a CPU hog, as is ogg/gstreamer... Yeah, ogg is consuming too much. I hope we can improve that. The gps parser needs to be profiled and then extended with a C module. I spoke too soon. They both work at the same time, which was not the case in 2007.2. :) However, they're still both CPU hogs... I've been looking into the ogg stuff a bit. I think the first step is to update the ivorbis package. That'll make it easier to try the low-mem branch and tremolo. I tried doing this a while back, but got runtime linker errors from gstreamer. Then I got busy with other things. There are also some other potential issues. I think gstreamer is doing software volume control, and there might be some grossness involving ARM's synchronization primitives. Unfortunately, I haven't gotten a profiler working to see exactly where the cycles are going. -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
Am Freitag 15 August 2008 09:02:42 schrieb Russell Sears: Michael 'Mickey' Lauer wrote: Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Cool. Headphone insertion isn't detected yet, but it does mute/stop the music when you pick up the phone). Please add a ticket. Where? I just added a bunch of FSO tickets to http://docs.openmoko.org/trac/; which has an FSO option in the milestone pulldown menu. Then I found trac.freesmartphone.org Hmm, ok. I'll remember these. In the future, until there's a software that includes the framework, I'd rather like to see the bugs in trac.freesmartphone.org. However, they're still both CPU hogs... I've been looking into the ogg stuff a bit. I think the first step is to update the ivorbis package. Ok. I try to find someone to look into that. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
On Thu, Aug 14, 2008 at 23:32 (-0700), Russell Sears wrote: The package I'm using (and dependency packages) is now up at http://hedora.ath.cx/moko/ Thanks! Most dependencies I already had installed from the °angström-base-feed. To install your mediaplayer-package I only had to change the corresponding md5-sum in /var/lib/opkg/base. Note that the player also works if openmoko-soundsystem2 is not installed -- even better: no pulseaudio running saves quite some CPU-cycles. I simply tried that as I didn't felt comfortable with pulseaudio returning to my moko and so far it works for me. Only the GUI is buggy and sometimes not responsive, but I suppose that's not related to the sound output. On the cpu-hogging: playing mp3s takes constantly ~30% (with and without pulseaudio). But mplayer also uses 25%, while in OM2007.2 it was around 10%. So maybe this is not a mediaplayer-issue but one of the sound-subsystem? Cheers, /Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
Lovely. Thanks. Can someone please test and wikify? Thanks, Michael Russell Sears wrote: The package I'm using (and dependency packages) is now up at http://hedora.ath.cx/moko/ Let me know if you hit any problems. -Rusty Russell Sears wrote: There are a bunch of manual steps right now: - openmoko-mediaplayer is hardcoded to use pulseaudio. Switching to alsa is a one-line change. - the mediaplayer theme files need to live in the Raleigh directory not in Moko - There's some dependency on a openmoko sound system. I don't know what it does, or if it's needed. - I pulled packages out of my mokomakefile, and installed them using opkg - there are lots of pulseaudio dependencies to be removed, so I used opkg --force-depends to install the mediaplayer package. Some of the packages may be unnecessary / cause breakage. My home server is down at the moment, so I don't have anywhere to stick the modified binary... I'll figure out what's going on with it and post better directions and the binary tonight. -Rusty Benito wrote: On Thu, Aug 14, 2008 at 10:08 (-0700), Russell Sears wrote: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Would you provide that to us? I'd like to use it, too. Thx, /Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
Michael 'Mickey' Lauer wrote: Am Freitag 15 August 2008 09:02:42 schrieb Russell Sears: Michael 'Mickey' Lauer wrote: Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Cool. Headphone insertion isn't detected yet, but it does mute/stop the music when you pick up the phone). Please add a ticket. Where? I just added a bunch of FSO tickets to http://docs.openmoko.org/trac/; which has an FSO option in the milestone pulldown menu. Then I found trac.freesmartphone.org Hmm, ok. I'll remember these. In the future, until there's a software that includes the framework, I'd rather like to see the bugs in trac.freesmartphone.org. Maybe the openmoko trac should document this, by adding the following sentence to the create new ticket page: Problems with the FSO framework and images should be reported to the freesmartphone.org trac trac should link to trac.freesmartphone.org Are there other trac's that bug reporters should know about? Also, I hit a bug involving the events thread and avahi-daemon on an FSO image. Where does that go? I ask so the answer can be documented on the 'create new ticket page' or somewhere on the wiki... ;) However, they're still both CPU hogs... I've been looking into the ogg stuff a bit. I think the first step is to update the ivorbis package. Ok. I try to find someone to look into that. Great! Though getting oprofile working (as a easy-to-install package) is a higher priority IMHO. Needing to move ivorbis to some combination of low-mem, tremolo and low-accuracy mode is my best guess, but it could be that gstreamer is doing something silly to oggs, but not mp3s, or some other strange problem... (see https://docs.openmoko.org/trac/ticket/1614 for ogg stuff, and https://docs.openmoko.org/trac/ticket/1193 for problems with IPC and arm's synchronization primitives.) Also, for packages like ivorbis, which repository / distribution should people repackage for? Is angstrom upstream of everyone else? Is there a URL/wikipage somewhere? I spent a few hours with the wiki trying to answer this question for openmoko-mediaplayer2 last night... -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
Benito wrote: On Wed, Aug 13, 2008 at 14:06 (-0700), Russell Sears wrote: It works immediatly with FSO and I could phone while GPRS is on. Really?!? How? Is there a GUI somewhere, or did you edit the PPP scripts to enter your provider settings? See http://wiki.openmoko.org/wiki/GPRS_FSO The script works flawless here, too. Nice. I was beginning to think my GPRS modem was busted. ;) I wonder if power management is working yet. The pppd docs say leaving gprs on eats lots of power. (The whole battery in 2 hours...) The wiki page says that it doesn't interfere with phone calls, but doesn't go into more detail. Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Headphone insertion isn't detected yet, but it does mute/stop the music when you pick up the phone). Now I just need music and tangogps to work at the same time. The framework gps thing is a CPU hog, as is ogg/gstreamer... -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Cool. Headphone insertion isn't detected yet, but it does mute/stop the music when you pick up the phone). Please add a ticket. Now I just need music and tangogps to work at the same time. The framework gps thing is a CPU hog, as is ogg/gstreamer... Yeah, ogg is consuming too much. I hope we can improve that. The gps parser needs to be profiled and then extended with a C module. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
On Thu, Aug 14, 2008 at 10:08 (-0700), Russell Sears wrote: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Would you provide that to us? I'd like to use it, too. Thx, /Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS under FSO [Was: Re: What could be done to improve the OM development process?]
There are a bunch of manual steps right now: - openmoko-mediaplayer is hardcoded to use pulseaudio. Switching to alsa is a one-line change. - the mediaplayer theme files need to live in the Raleigh directory not in Moko - There's some dependency on a openmoko sound system. I don't know what it does, or if it's needed. - I pulled packages out of my mokomakefile, and installed them using opkg - there are lots of pulseaudio dependencies to be removed, so I used opkg --force-depends to install the mediaplayer package. Some of the packages may be unnecessary / cause breakage. My home server is down at the moment, so I don't have anywhere to stick the modified binary... I'll figure out what's going on with it and post better directions and the binary tonight. -Rusty Benito wrote: On Thu, Aug 14, 2008 at 10:08 (-0700), Russell Sears wrote: Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked up a openmoko-mediaplayer package. Would you provide that to us? I'd like to use it, too. Thx, /Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wed, Aug 13, 2008 at 12:05 AM, Jeffery Davis [EMAIL PROTECTED] wrote: 1. Instead of working on multiple concurrent software distributions, why not try to rally everyone under one banner for a while? Just my cheap comment on this : I feel less and less like there's multiple concurrent software distributions. There was the gsmd-based stack, but it doesn't look like OM is working on it. ASU and FSO looks more and more like two parts of the same thing to me : ASU has some very interesting EFL apps (beside phone apps), and FSO's phone app (zhone) is based on EFL too. So the future merge of the two branches (or half-branches, if I'm right) shouldn't be that hard nor hypothetical. My 2 cents. -- Olivier M. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
Am Mittwoch 13 August 2008 09:24:46 schrieb Olivier Migeot: On Wed, Aug 13, 2008 at 12:05 AM, Jeffery Davis [EMAIL PROTECTED] wrote: 1. Instead of working on multiple concurrent software distributions, why not try to rally everyone under one banner for a while? Just my cheap comment on this : I feel less and less like there's multiple concurrent software distributions. There was the gsmd-based stack, but it doesn't look like OM is working on it. ASU and FSO looks more and more like two parts of the same thing to me : ASU has some very interesting EFL apps (beside phone apps), and FSO's phone app (zhone) is based on EFL too. So the future merge of the two branches (or half-branches, if I'm right) shouldn't be that hard nor hypothetical. FSO is about the framework. It's _not_ a second distribution worked on by the Openmoko team. It rather exposes the framework-level work with some example code. Here are the only reasons FSO exists as an image and not just as a couple of ipks: a) Middleware is invisible. b) Defining APIs without working on an API consumer seldomly lead to something good. I was afraid all this confusion would arise, that's why I (thought I) made it clear enough on the framework wiki page and the blogs. Trust me, to avoid it, for a while I really considered shipping a console-image for the framework image, forcing people to ssh into to start getting familiar with the dbus services... -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
Trust me, to avoid it, for a while I really considered shipping a console-image for the framework image, forcing people to ssh into to start getting familiar with the dbus services... hum ... personnaly, I use it. I couldn't get my GPRS work on ASU. It works immediatly with FSO and I could phone while GPRS is on. So please, if you do this, build also the wm and allowing us to install it ... Or do I have to give another try to 2008.8 ? My previous one wasn't successful ... Mike Michael 'Mickey' Lauer a écrit : Am Mittwoch 13 August 2008 09:24:46 schrieb Olivier Migeot: On Wed, Aug 13, 2008 at 12:05 AM, Jeffery Davis [EMAIL PROTECTED] wrote: 1. Instead of working on multiple concurrent software distributions, why not try to rally everyone under one banner for a while? Just my cheap comment on this : I feel less and less like there's multiple concurrent software distributions. There was the gsmd-based stack, but it doesn't look like OM is working on it. ASU and FSO looks more and more like two parts of the same thing to me : ASU has some very interesting EFL apps (beside phone apps), and FSO's phone app (zhone) is based on EFL too. So the future merge of the two branches (or half-branches, if I'm right) shouldn't be that hard nor hypothetical. FSO is about the framework. It's _not_ a second distribution worked on by the Openmoko team. It rather exposes the framework-level work with some example code. Here are the only reasons FSO exists as an image and not just as a couple of ipks: a) Middleware is invisible. b) Defining APIs without working on an API consumer seldomly lead to something good. I was afraid all this confusion would arise, that's why I (thought I) made it clear enough on the framework wiki page and the blogs. Trust me, to avoid it, for a while I really considered shipping a console-image for the framework image, forcing people to ssh into to start getting familiar with the dbus services... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. The benefit of having as precise tasks as possible is that they are small, can be assigned to a single person, one can set the severity and the milestone. After this small task was done, the engineer can set it to in_testing and QA can test that single fix. Now we have bugreports like the SIM PIN Dialog or the Keyboard. No doubt that there is a real issue but they are the exact the opposite of the above workflow. We can not assign a single engineer to take care of them. This means they will never be addressed as no one is responsible and not many people are capable of touching everything that would be needed to resolve the bug. So how to get out of that? Look at the issues presented and file tickets for each single issue. These can be assigned to developers, these can have a milestone set, these can have a severity, these fixes can actually be tested and verified. With my limited resources, internet connectivity (GPRS through the neo), my available time and my main tasks in mind, I have simply no time to create the tickets for each and every issue. So I name the issues I see in the report (and yes the list can be incomplete) and rely on people/interest holders to file a new precise bug report. This is to make it possible for engineers actually being able to do a bugfix which is in the interest of the community... Is that bad faith? How do others see that? your pighead z. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote: On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. Don't forget the problem reports which are a valuable source of feedback for those developers. So the bugtracker is also for reporting bugs and enhancement wishes. The benefit of having as precise tasks as possible is that they are small, can be assigned to a single person, one can set the severity and the milestone. After this small task was done, the engineer can set it to in_testing and QA can test that single fix. In an ideal world it would something like this. Now we have bugreports like the SIM PIN Dialog or the Keyboard. No doubt that there is a real issue but they are the exact the opposite of the above workflow. We can not assign a single engineer to take care of them. This means they will never be addressed as no one is responsible and not many people are capable of touching everything that would be needed to resolve the bug. So how to get out of that? Look at the issues presented and file tickets for each single issue. These can be assigned to developers, these can have a milestone set, these can have a severity, these fixes can actually be tested and verified. With my limited resources, internet connectivity (GPRS through the neo), my available time and my main tasks in mind, I have simply no time to create the tickets for each and every issue. So I name the issues I see in the report (and yes the list can be incomplete) and rely on people/interest holders to file a new precise bug report. This is to make it possible for engineers actually being able to do a bugfix which is in the interest of the community... Is that bad faith? How do others see that? No, it is just a gap. Users expect that developer understand their concerns (you should know what it in it is broken means) and developer expect that users understand their concerns (they should report e.g. that component X makes wrong assumption and produces a race condition). In between there is a huge gap. While the sentence improve the communication is complete non-sense it indicates at least the helpless- ness how to bridge the gap. In my opinion bridging the gap means translation of the language from the consumer to the engineer. I know only two things that can bridge this gap: - if problem reports are written as reproducable misbehaviour one can report it and developer can reproduce the same thing to find his own words/ the real issue behind it. Then the engineer should translate the ticket (subject) to the real thing - community workers can leverage this manually by trying to understand the customer and having enough knowledge to know how the engineer needs the information in order to be able to work. As this is a boring job you have to be paid for it (hello moko). That is nothing you can expect from people to do in their spare time. It is difficult and I could write pages with all those aspects of community vs. paid workers, product vs. development platform, widget set A vs. widget set B and so on. But it would be even more boring than this mail. So I let it go :) My experience is that working with a ticket system takes a lot of time. Don't take tickets statically. Change them as you would change code when you recognize that it doesn't work. That way a unspecific user complaint could be turned into something valuable. And workarounds are workarounds and they are useful until real issues have been fixed. Regarding the No SIM pin dialog where I was involved the ticket isn't that bad. There is an issue recognized no sim pin dialog while qpe is eating your device. And there is a workaround. So why not open a ticket qpe does not detect media files on the SD card which is blocked by the no sim pin ticket? In the sim pin ticket you can announce the work- around and in the second ticket you can complain about the shitty workaround. But then it is clear. The workaround isn't good and has to be removed as soon as the first issue is solved. In the meantime it does something good. My proposal for the ticket system would be to define rules. As soon as you have a page which describes when a ticket is useful and when it is not you can reject tickets from users pointing to that page. That sounds harsh at first but becomes useful really quick because this is a restriction where the community benefits. The
Re: What could be done to improve the OM development process?
On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. You shouldn't understand a community as the incarnation of a collective dictatorship. There is still a company that may have other ideas than everybody in the community. That is ok. It is rather that people have problems in understanding the openness in those things. You are not forced by anyone to use the keyboard. You can change it any time. If you don't like much more things you can even fork the whole thing and make like you expect it. No intellectual property hassle, you are free to do it. That sounds like the same dumb answers before? Yes, it reads like a big excuse for everything from the community members. But there is one thing why this is the way to answer such things. Projects like openmoko survive from people that do anything for it. It is starving through simple complaints, tons of enhancement wishes and the public management of sensitivities . So for me it is the ultimate justice that the people that do decide what to do. If a company pays people to do the work that nobody likes to do than everything is perfect :) hmm, there are a lot of cents in my pocket today :) Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote: On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote: On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. Don't forget the problem reports which are a valuable source of feedback for those developers. So the bugtracker is also for reporting bugs and enhancement wishes. The benefit of having as precise tasks as possible is that they are small, can be assigned to a single person, one can set the severity and the milestone. After this small task was done, the engineer can set it to in_testing and QA can test that single fix. In an ideal world it would something like this. Now we have bugreports like the SIM PIN Dialog or the Keyboard. No doubt that there is a real issue but they are the exact the opposite of the above workflow. We can not assign a single engineer to take care of them. This means they will never be addressed as no one is responsible and not many people are capable of touching everything that would be needed to resolve the bug. So how to get out of that? Look at the issues presented and file tickets for each single issue. These can be assigned to developers, these can have a milestone set, these can have a severity, these fixes can actually be tested and verified. With my limited resources, internet connectivity (GPRS through the neo), my available time and my main tasks in mind, I have simply no time to create the tickets for each and every issue. So I name the issues I see in the report (and yes the list can be incomplete) and rely on people/interest holders to file a new precise bug report. This is to make it possible for engineers actually being able to do a bugfix which is in the interest of the community... Is that bad faith? How do others see that? No, it is just a gap. Users expect that developer understand their concerns (you should know what it in it is broken means) and developer expect that users understand their concerns (they should report e.g. that component X makes wrong assumption and produces a race condition). In between there is a huge gap. While the sentence improve the communication is complete non-sense it indicates at least the helpless- ness how to bridge the gap. In my opinion bridging the gap means translation of the language from the consumer to the engineer. I know only two things that can bridge this gap: - if problem reports are written as reproducable misbehaviour one can report it and developer can reproduce the same thing to find his own words/ the real issue behind it. Then the engineer should translate the ticket (subject) to the real thing - community workers can leverage this manually by trying to understand the customer and having enough knowledge to know how the engineer needs the information in order to be able to work. As this is a boring job you have to be paid for it (hello moko). That is nothing you can expect from people to do in their spare time. It is difficult and I could write pages with all those aspects of community vs. paid workers, product vs. development platform, widget set A vs. widget set B and so on. But it would be even more boring than this mail. So I let it go :) My experience is that working with a ticket system takes a lot of time. Don't take tickets statically. Change them as you would change code when you recognize that it doesn't work. That way a unspecific user complaint could be turned into something valuable. And workarounds are workarounds and they are useful until real issues have been fixed. Regarding the No SIM pin dialog where I was involved the ticket isn't that bad. There is an issue recognized no sim pin dialog while qpe is eating your device. And there is a workaround. So why not open a ticket qpe does not detect media files on the SD card which is blocked by the no sim pin ticket? In the sim pin ticket you can announce the work- around and in the second ticket you can complain about the shitty workaround. But then it is clear. The workaround isn't good and has to be removed as soon as the first issue is solved. In the meantime it does something good. My proposal for the ticket system would be to define rules. As soon as you have a page which describes when a ticket is useful and when it is not you can reject tickets from users pointing to that page. That sounds harsh at
Re: What could be done to improve the OM development process?
Holger Freyther [EMAIL PROTECTED] writes: On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. Whereas us users have been assuming that it was an open bugtracker for en-users... Maybe there would be a need for some other Bug-tracking tool, which would clearly support the separation between support-oriented bugtracker (external) and engineering-oriented one (internal maybe) ? I don't think trac's is powerful enough to play both roles without much frustration from either side (but I may be wrong). In any case, a policy should be drafted and announced widely. And mailing-lists for users vs bugtracker for engineering is not satisfactory for any open project, of course. Also, maybe you would need to rely on an organisational tool like a todo manager to assign work to people, whereas bugtrackers may only be there as a repository of knowledge and a communication tool ? My 2 cents. Best regards, -- Olivier BERGER (OpenPGP: 1024D/B4C5F37F) http://www.olivierberger.com/weblog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
I mistakenly sent this response via private email to Carsten when I meant to post it to the list. Original Message Subject:Re: What could be done to improve the OM development process? Date: Tue, 12 Aug 2008 20:58:41 -0400 From: Jeffery Davis [EMAIL PROTECTED] To: Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] aaah - but this is what om wants! as per will's words (product management for OM): Everyone should fork. Everyone should create their own distribution ( quoted from: From: [EMAIL PROTECTED] To: List for Openmoko community discussion community@lists.openmoko.org Subject: Re: Community contributions to core apps features. (Was: Terminal forASU) Date: Sat, 26 Jul 2008 11:44:21 + ) this is om's intention and desire. Explain to me the reasoning behind forking the software at this point. What does it accomplish, besides paying lip service to choice? I'm thinking of the Bible story of Solomon and the two mothers here. What good is half a baby? Wait until there's something /worth/ forking. Can anyone name a product that succeeded by encouraging everyone to fork immediately? I can't think of any examples. F/OSS gives you the /ability/ to fork, but that doesn't mean it's always a good idea or a goal in and of itself. In fact, I think the decision to fork is one that should be made with some gravity. There's a whole world between the cathedral and the bazaar. rock | om engineers | hard place. om design specifies what keyboard it wants. you are to fork and do your own thing if you don't like it. Forking over a keyboard is silly. Almost as silly as not listening to the people that paid money for your product. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
aaah - but this is what om wants! as per will's words (product management for OM): Everyone should fork. Everyone should create their own distribution ... this is om's intention and desire. Explain to me the reasoning behind forking the software at this point. silly me believing not understanding irony was an entirely german disease ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
silly me believing not understanding irony was an entirely german disease ... He said the intention was basically 'fork early, fork often'. I simply asked 'Why?' He didn't explain the reasoning. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
Explain to me the reasoning behind forking the software at this point. What does it accomplish, besides paying lip service to choice? I'm thinking of the Bible story of Solomon and the two mothers here. What good is half a baby? Wait until there's something /worth/ forking. Can anyone name a product that succeeded by encouraging everyone to fork immediately? I can't think of any examples. F/OSS gives you the /ability/ to fork, but that doesn't mean it's always a good idea or a goal in and of itself. In fact, I think the decision to fork is one that should be made with some gravity. There's a whole world between the cathedral and the bazaar. It really boils down to this: encouraging mass forkage in the community is a closed-sourcers weapon against the establishment of a stable community. Microsoft - and others who wish to combat the open source phenomenon - widely encourage forking as it is a sure-fire way to kill public interest in a project. After all, with too many forks, eventually people give up in the confusion. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
silly me believing not understanding irony was an entirely german disease ... He said the intention was basically 'fork early, fork often'. I simply asked 'Why?' He didn't explain the reasoning. There is no reasoning. Its a destructive policy, plain and simple. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wed, 2008-08-13 at 14:09 +0200, Olivier Berger wrote: Holger Freyther [EMAIL PROTECTED] writes: On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. Whereas us users have been assuming that it was an open bugtracker for en-users... Maybe there would be a need for some other Bug-tracking tool, which would clearly support the separation between support-oriented bugtracker (external) and engineering-oriented one (internal maybe) ? Having two different tools raises complexity and lowers collaborative work. And what do you get from it? I don't think trac's is powerful enough to play both roles without much frustration from either side (but I may be wrong). In my opinion it is never the tool that prevents organized work. Not having the right tool is just the simplest excuse for being organized ;) In any case, a policy should be drafted and announced widely. And mailing-lists for users vs bugtracker for engineering is not satisfactory for any open project, of course. Also, maybe you would need to rely on an organisational tool like a todo manager to assign work to people, whereas bugtrackers may only be there as a repository of knowledge and a communication tool ? Wow, I think it is exactly the opposite. What a bugtracker does best is keeping things that have to be done. What it doesn't do so good is serve as a knowledge base or communication tool. We are communicating over a mailing list. For the rest (ticketing, wiki, source repository) trac tries to be a good integration of those systems. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote: Don't forget the problem reports which are a valuable source of feedback for those developers. So the bugtracker is also for reporting bugs and enhancement wishes. It is. In the SIM PIN Dialog bug the log was really helpful to identify the issue as I see it. Feedback is _very_ valuable. The benefit of having as precise tasks as possible is that they are small, can be assigned to a single person, one can set the severity and the milestone. After this small task was done, the engineer can set it to in_testing and QA can test that single fix. In an ideal world it would something like this. For bugs found by QA it is actually working that way. For the rest we should aim to get there as well. Is that bad faith? How do others see that? No, it is just a gap. Users expect that developer understand their concerns (you should know what it in it is broken means) and developer expect that users understand their concerns (they should report e.g. that component X makes wrong assumption and produces a race condition). In between there is a huge gap. While the sentence improve the communication is complete non-sense it indicates at least the helpless- ness how to bridge the gap. In my opinion bridging the gap means translation of the language from the consumer to the engineer. I know only two things that can bridge this gap: hehe, we never talked about domain specific languages (user - developer is a bit different though), but I'm not surprised you have looked into that. - if problem reports are written as reproducable misbehaviour one can report it and developer can reproduce the same thing to find his own words/ the real issue behind it. Then the engineer should translate the ticket (subject) to the real thing - community workers can leverage this manually by trying to understand the customer and having enough knowledge to know how the engineer needs the information in order to be able to work. As this is a boring job you have to be paid for it (hello moko). That is nothing you can expect from people to do in their spare time. Yes that is the difficult part. I don't get into details right now... :) My proposal for the ticket system would be to define rules. As soon as you have a page which describes when a ticket is useful and when it is not you can reject tickets from users pointing to that page. That sounds harsh at first but becomes useful really quick because this is a restriction where the community benefits. The rationale behind this is that everybody gains if _you_ are fixing code instead of managing tickets. yeah, this is work in progress. Stuff like two bug trackers, controlling some more fields.. and various other things float through my head and I have to organize this first. Other entities fix that by shielding developers and putting 1st line support there acting as a multiplexers... but I think reaching developers directly can be valuable.. cya tonight z. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
I don't know if I agree with the suggestions of this user, but since we're brainstorming, I have one thought :) Discrete components should be managed as separate packages with separate project pages and information and repositories and bug trackers and such. There's no reason for everything to be lumped together, especially if one of openmoko's stated goals is to facilitate user forking and contributions. This is the way linux works in the PC world. For example, binutils and bash are distributed separately, even though it would be hard to conceive of a system that needs one and not the other, and even though it's made by the exact same organization. It could be the same situation with illume and qtopia-x11 too. Aside from that I think they're doing a great job :) On Tuesday 12 August 2008 18:05:14 Jeffery Davis wrote: Two thoughts... 1. Instead of working on multiple concurrent software distributions, why not try to rally everyone under one banner for a while? People are going to work on what they want to work on to some degree, but an attempt should be made at least. Choice is great and all, but in the beginning I'd rather have one option that works well rather than three or four equally terrible options. There's no need to go running off in different directions when people still can't receive calls reliably, among other issues. 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Daniel Benoy http://daniel.benoy.name signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
Mike Baroukh wrote: Trust me, to avoid it, for a while I really considered shipping a console-image for the framework image, forcing people to ssh into to start getting familiar with the dbus services... Why try to avoid it? Isn't it the shortest path to a working phone? If the framework's working, shouldn't all the other stuff be easy to write? For me, FSO is the most stable image so far. I don't care too much about how the GUI looks, at least at this stage of the game. (Though 2008.8 looks pretty cool!) hum ... personnaly, I use it. I couldn't get my GPRS work on ASU. It works immediatly with FSO and I could phone while GPRS is on. Really?!? How? Is there a GUI somewhere, or did you edit the PPP scripts to enter your provider settings? So please, if you do this, build also the wm and allowing us to install it ... I think of FSO as a bear bones linux installation. It doesn't too much, but it's rock-solid, and ready to have new software installed. I just wish there was a unified repository for openmoko packages that held all packages written against FSO (ie: a superset of the stuff that comes with 2008.8 and FSO). I couldn't get anywhere with the 2008.8, and am not a fan of qtopia's approach to some things. However, I would like to use opkg to add some of SHR's software (and some 2007.2 software) to my FSO installation. It looks like I'll have to repackage / recompile quite a few programs that I'm interested in, which is a shame. (ie: the openmoko-mediaplayer ipk file I have wants pulseaudio for some reason...) Perhaps there should be 'tasks' metapackages. So, if you have FSO, but want to try out the SHR gui you just do this: opkg install task-shr Then, edit some .Xsession file to launch illume + qtopia. FSO with a 2007.2 look and feel would be this: opkg install matchbox and edit your .Xsession to start matchbox instead of illume (and probably port the matchbox panel stuff to new apis...). This approach has worked pretty well for debian over the years. Though now they've got ubuntu, kubuntu, xubuntu, etc. Instead of forking, OM and others could make images for different UIs. Pre-FSO, I don't think it would have worked for openmoko, since the underlying software stacks varied (and evolved) so much. But now, assuming everyone standardizes on FSO's middleware (which seems to be happening), getting it to work shouldn't be too bad. Also, it would let users avoid regressions like the ones associated with moving from 2007.2 to [SHR|QTopia|2008.8|FSO], since they could choose which apps to run, and try out new software without losing their old installations. -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
Holger Freyther wrote: yeah, this is work in progress. Stuff like two bug trackers, controlling some more fields.. and various other things float through my head and I have to organize this first. Other entities fix that by shielding developers and putting 1st line support there acting as a multiplexers... but I think reaching developers directly can be valuable.. I second Norbert Hartl on this one. Having two different tools raises complexity and lowers collaborative work. And what do you get from it? As a dev who works with bugzilla internally and with clients, any plans to separate the devs from the users put a chill through me. I wouldn't advise trying separate work in to two bug trackers as you lose the value in the crossover, and a good bug tracker makes it easy to sift out the important information. In my experience as a dev, any kind of first line support ends up filtering out most of the useful information and can't actually provide high quality answers to technical users. This results in worse software for the user and ironically more support requests. For everything except phone support, direct contact with the devs is far superior. An idea I came across recently that seems like a good idea is a hybrid approach, where the devs passively observe /all/ traffic from users (irc, mailing lists, support mailboxes, bug trackers etc), and can pick out bits that are useful, and then there are additional people paid to respond to all the rtfm type questions. That way you get the best of both worlds. The techies don't have the most valuable information lost in translation, and the more demanding users get the support they desire without wasting valuable coding time. Tim Abell ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
Bear in mind reading this that I'm aware I know nothing of your internal workings, and wouldn't presume to know better. I just hope to contribute something from my experiences, and will take no offence if ignored. Holger Freyther wrote: --- Now we have bugreports like the SIM PIN Dialog or the Keyboard. No doubt that there is a real issue but they are the exact the opposite of the above workflow. We can not assign a single engineer to take care of them. This means they will never be addressed as no one is responsible and not many people are capable of touching everything that would be needed to resolve the bug. I disagree, you /can/ assign them to a single engineer (even if they don't like it!), and they can then in turn break it down to constituent parts (bugs) that have clear engineer ownership. As an engineer I don't like having bugs on my list that I see no clear path to fixing, so will dig down into the details till I have a good description of the problem and a plan for resolving it, however convoluted. Being responsible for a bug doesn't necessarily mean being the person who actually makes the code changes, just the person who keeps revisiting it till it's done (depending on importance). So how to get out of that? Look at the issues presented and file tickets for each single issue. These can be assigned to developers, these can have a milestone set, these can have a severity, these fixes can actually be tested and verified. With my limited resources, internet connectivity (GPRS through the neo), my available time and my main tasks in mind, I have simply no time to create the tickets for each and every issue. So I name the issues I see in the report (and yes the list can be incomplete) and rely on people/interest holders to file a new precise bug report. This is to make it possible for engineers actually being able to do a bugfix which is in the interest of the community... Is that bad faith? How do others see that? I see no bad faith here :-) Personally I think bug trackers (I use bugzilla for my dev work) have no trouble supporting both user oriented and developer oriented reports. Where there is an apparent disconnect between the points of view, eg user: i can't phone fred dev: d-bus message foo is malformed by obscure component x, both reports can co-exist, and a dependency can show the relationship between them, ie the user can't phone fred (bug #1) until the d-bus problem (bug #2) is corrected (blocks bug #1). In my experience, if a user files a vague (but eventually reproducable) bug report, then the bug report lands in my virtual in-tray, and once I've figured out the cause (with my developer hat on) I will perhaps file a more detailed separate report and link the two if appropriate. I make it my mission to never have any bugs in my in-tray that I haven't analysed down to the root cause. So I guess what I'm saying is the bug reports need to be assigned to someone with sufficient knowledge to either get to the root cause or re-assign it to someone who they think can. If you personally don't know how to fill in details for a bug report then, simply reassign it to a suitable engineer, and then (depending on organisational structure) kick them till it's understood/done, or ask them nicely to look at it. :-) Tim Abell ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Thu, 14 Aug 2008 00:29:44 +0100 tim [EMAIL PROTECTED] babbled: An idea I came across recently that seems like a good idea is a hybrid approach, where the devs passively observe /all/ traffic from users (irc, mailing lists, support mailboxes, bug trackers etc), and can pick out bits that are useful, and then there are additional people paid to respond to all the rtfm type questions. That way you get the best of both worlds. The techies don't have the most valuable information lost in translation, and the more demanding users get the support they desire without wasting valuable coding time. i've been doing this for a decade... sit on irc - watch mostly passively what the major bitching/complaining seems to be. watch email - and just scan most mail so you know what the major issues seem to be. a lot are RTFM-like. ignore those (except the first few times you see them - let community repeat what you said earlier for you). watch bug tickets and at lest get a gist for that's up at the moment. respond to things you directly know about and can do something about (or know you can't), and from that snarf a TODO list. generally this should keep you busy 24/7 given a large enough project :) -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wed, Aug 13, 2008 at 14:06 (-0700), Russell Sears wrote: It works immediatly with FSO and I could phone while GPRS is on. Really?!? How? Is there a GUI somewhere, or did you edit the PPP scripts to enter your provider settings? See http://wiki.openmoko.org/wiki/GPRS_FSO The script works flawless here, too. I think of FSO as a bear bones linux installation. It doesn't too much, but it's rock-solid, and ready to have new software installed. So do I and I really appreciate it. What really makes me passionate about my neo is the possibility to control it completely and know how it works. FSO gives me much more freedom to make my own phone instead of fighting with pre-stuffed and fancy but slow, unstable and intransparent environments. The beauty of KISS proves itself. The only choice I'm not happy with is enlightenment/illume, which I didn't make friends with. Binary configuration files is a no-no AFAIC, and also the complexity of the e-universe (efl, eet, ewl, edje, etc) makes me frown up to now. (I know this wasn't an FSO-specific choice, but that doesn't make it better.) And a second, following complaint: I'd appreciate some more information for (becoming) developers on illume (and other components). A wiki-stub, a 2-lines README and a trivial INSTALL-file is somewhat too little for the introduction to the new and otherwise poorly documented windowmanager one shall work with from now on (hints welcome). My impression is that all the chattiness of users trying to cope with the different GUIs drowns the attention for the needs of people willing to participate more actively. At the moment crossing the gap from being a user to (seriously, not trollingly) taking part in the developing community needs quite an efford. If there was a little more help or even guidance in this (technical howtos, code references, man-pages, dedicated irc-channels, ...) some energy could be invested more productively. But in any way: a big Thank You to you FSO-developers! Your choice to develop and release(!) this non-distribution opened space and made things fun again! Cheers, /Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Tue, 12 Aug 2008 18:05:14 -0400 Jeffery Davis [EMAIL PROTECTED] babbled: Two thoughts... 1. Instead of working on multiple concurrent software distributions, why not try to rally everyone under one banner for a while? People are going to work on what they want to work on to some degree, but an attempt should be made at least. Choice is great and all, but in the beginning I'd rather have one option that works well rather than three or four equally terrible options. There's no need to go running off in different directions when people still can't receive calls reliably, among other issues. aaah - but this is what om wants! as per will's words (product management for OM): Everyone should fork. Everyone should create their own distribution ( quoted from: From: [EMAIL PROTECTED] To: List for Openmoko community discussion community@lists.openmoko.org Subject: Re: Community contributions to core apps features. (Was: Terminal forASU) Date: Sat, 26 Jul 2008 11:44:21 + ) this is om's intention and desire. 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. rock | om engineers | hard place. om design specifies what keyboard it wants. you are to fork and do your own thing if you don't like it. if you trawl through the mail archives you'll know why. the keyboard has been flamed about enough. i'm not going to touch it. -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
