Reply
Thread Tools
Posts: 90 | Thanked: 32 times | Joined on Sep 2006 @ Bucuresti, Romania
#71
Nathan, I think that developers absolutely need devices to work with, and I'm saying this as one developer professionally working with mobile devices for more than three years ! Real devices do NOT behave as tested on SDK, apart for the most simple programs.

I'm proposing on the list iancumihai, developer of myTube, very appreciated piece of software.
 
Bundyo's Avatar
Posts: 4,708 | Thanked: 4,649 times | Joined on Oct 2007 @ Bulgaria
#72
Originally Posted by VDVsx View Post
I think nobody with pre-production devices asked for a new one at the summit AFAIK, that would be very greedy attitude IMHO.
Actually I had my prototype exchanged when Daniel discovered it had older bootloader and can't be upgraded to 41-10 at least at the spot.
__________________
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#73
Originally Posted by ddalex View Post
Nathan, I think that developers absolutely need devices to work with, and I'm saying this as one developer professionally working with mobile devices for more than three years ! Real devices do NOT behave as tested on SDK, apart for the most simple programs.
I never said it was easy. ;-) I said it was work-able without a device. Trust me I am well aware of how "very" hard it can be trying to debug something remotely w/o having a device. (I've been doing development for over 20 years) -- And to top that off my own learning style (and my ability to debug) is completely hands on/physical. My wife hates when I "show" her how to fix a problem because I literally have to take control of her machine -- I can't verbally walk her through it. I am a very hands on type of person. But the point is yes the device would be very nice, and it would allow certain tests to be easily performed. But most things can be done in the scratchbox and tested their. You can get it running; then you can ask the community to vet the project and make sure their are no other "oddities" that show up on the real device. If you are unaware -- you need to know the Scratchbox runs the same versions of the software the device does. When I pull a library from extras in the scratchbox; it is the same library a n900 would pull. So they are a lot closer than I think you think they are.

Nathan
 
allnameswereout's Avatar
Posts: 3,397 | Thanked: 1,212 times | Joined on Jul 2008 @ Netherlands
#74
Originally Posted by Nathan View Post
I never said it was easy. ;-) I said it was work-able without a device. Trust me I am well aware of how "very" hard it can be trying to debug something remotely w/o having a device. (I've been doing development for over 20 years) -- And to top that off my own learning style (and my ability to debug) is completely hands on/physical. My wife hates when I "show" her how to fix a problem because I literally have to take control of her machine -- I can't verbally walk her through it. I am a very hands on type of person. But the point is yes the device would be very nice, and it would allow certain tests to be easily performed. But most things can be done in the scratchbox and tested their. You can get it running; then you can ask the community to vet the project and make sure their are no other "oddities" that show up on the real device. If you are unaware -- you need to know the Scratchbox runs the same versions of the software the device does. When I pull a library from extras in the scratchbox; it is the same library a n900 would pull. So they are a lot closer than I think you think they are.
I agree the SDK can get you far but it isn't a complete replacement and it probably will never be. You stated in earlier post:

you developers do not need a device to get things going at all!
(Emphasis mine.)

..and that is not true.

The Scratchbox+SDK platform does not use the same architecture the target platform uses. It either runs x86-32 software, or uses QEMU to emulate ARMEL. QEMU contains bugs. For example, see cmake thread, or fact it doesn't run GUI, and sometimes my ARMEL environment is screwed and I have no clue what happened. So architecture specific problems are concern. It is also difficult to test usability without touchscreen and finger/stylus using mouse instead. I wonder how Nokia deals with this internally?!

Which brings me to Scratchbox not emulating certain hardware features the real device has. For example, I've seen posts about using GPS and Bluetooth inside the SDK. The former is easy to solve (gpsd or gpsfake running on host platform port 2947 reachable from Scratchbox) but the latter is a bit harder to solve. Another example, and that is my main reason, is that it doesn't emulate performance of Nokia N900 rendering tools such as htop, iotop, powertop, latencytop, nearly useless.

Although the number of situations these problems arise is up for debate, karma reflects past effort not present or future effort, and I'm not saying above must be fixed (is difficult), it is IMO important to take note.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
 
qgil's Avatar
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#75
To recap, my counter proposal to "Proposal: To include some Core Members with low Karma in Dev Program" is "To create a waiting list of community projects to get a loaned device when available".

It would be more practical to discuss on practical priorities (what goes first, e.g. MMS or Java?) rather than theoretical karma weaknesses.

You can still discuss the latter but please use another thread for that. Even if you are convincing any changes on karma calculations won't affect directly the N900 program anymore.
 

The Following User Says Thank You to qgil For This Useful Post:
bergie's Avatar
Posts: 381 | Thanked: 847 times | Joined on Jan 2007 @ Helsinki
#76
Originally Posted by andrewfblack View Post
The problem has come up that some Core Members of Maemo Community are left out of dev discount program because they have low karma. For one reason or another thy have either are newer members or don't make use of maemo.org services.
I just got an idea: how about making it possible to donate some of your karma to others? If you are an active contributing member of the community you're likely to have a lot of it, and probably can identify promising new community members who'd deserve to have more.

That way we could still utilize karma for things like developer device program and travel sponsorship eligibility, but make them also accessible to new members of our community.
 

The Following 7 Users Say Thank You to bergie For This Useful Post:
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#77
Originally Posted by allnameswereout View Post
I agree the SDK can get you far but it isn't a complete replacement and it probably will never be. You stated in earlier post:
Originally Posted by nathan
you developers do not need a device to get things going at all!
..and that is not true.

The Scratchbox+SDK platform does not use the same architecture the target platform uses. It either runs x86-32 software, or uses QEMU to emulate ARMEL. QEMU contains bugs. For example, see cmake thread, or fact it doesn't run GUI, and sometimes my ARMEL environment is screwed and I have no clue what happened. So architecture specific problems are concern. It is also difficult to test usability without touchscreen and finger/stylus using mouse instead. I wonder how Nokia deals with this internally?!
Trust me I am well aware of a lot of the issues with the scratchbox (both 1 and 2) -- in fact if you look at the cmake thread (that you referenced) you will see I also reported the exact same issue one or two posts later -- I also followed up and put a bug in to the bugtracker and posted to the dev list and got the ball rolling to get the issue fixed once it was a confirmed bug and we knew where to look/fix it. (In fact, had Nokia not fixed it as fast as they had, I had an alternative method that I was going to deploy to the repositories to work around the issue)

However, in the meantime even with that "blocking" bug, I was still able to test everything on the x86 side and get several other issues resolved while I waited (1 day) for Nokia to get the issue fixed on the armel side of things. I couldn't ask for better turn around on that fix!

Which brings me to Scratchbox not emulating certain hardware features the real device has. For example, I've seen posts about using GPS and Bluetooth inside the SDK. The former is easy to solve (gpsd or gpsfake running on host platform port 2947 reachable from Scratchbox) but the latter is a bit harder to solve. Another example, and that is my main reason, is that it doesn't emulate performance of Nokia N900 rendering tools such as htop, iotop, powertop, latencytop, nearly useless.
Yes, their are some things it won't emulate or handle properly. But again the vast majority of things it is usable for. If you are doing a project that requires a live camera feed -- yes, you need the hardware. I stated for most things the sdk is fine.


Although the number of situations these problems arise is up for debate, karma reflects past effort not present or future effort, and I'm not saying above must be fixed (is difficult), it is IMO important to take note.
If you go towards the TOP of this thread you will see that I am a very strong believer in developers (I complained and lobbied hard in a couple threads over possible cracks -- and I assume based on some of the responses I annoyed some people.). But based on their response I do firmly believe Quim, Nokia, and the CC is doing the best job they can do with the information and resources they have. I provided a list of potential cracks where developers may have fallen through; and they didn't just brush it off -- they took it seriously. I'm not saying they (Quim, Nokia, and the CC) won't make mistakes -- but they do appear to be attempting to look out for the best interest of the community and that is really all we can ask for! (Again, way to go Quim, Nokia and CC!)

Nathan.
 
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#78
Originally Posted by qgil View Post
To recap, my counter proposal to "Proposal: To include some Core Members with low Karma in Dev Program" is "To create a waiting list of community projects to get a loaned device when available".
Off of my list (any any other list) do we have a list of those who actually got devices. It might make it easier to see which projects need to be put on the waiting list.

Nathan.
 
ossipena's Avatar
Posts: 3,159 | Thanked: 2,023 times | Joined on Feb 2008 @ Finland
#79
it is impossible to measure accurately everybodys work for the community. that's why whe should only improve the calculation formulas for karma if karma is used to measure one's activity and possible rewards are given based to karma.

There will always somebody who's left out. But if majority have justified discounts, I'd say the system works very well.

Of course if something exceptional (must be really awesome) appears and author doesn't get reward that he should, it should be like nobel prize of peace, one per year or something like that.
 

The Following User Says Thank You to ossipena For This Useful Post:
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,681 times | Joined on Mar 2008 @ UK
#80
Originally Posted by bergie View Post
I just got an idea: how about making it possible to donate some of your karma to others?
This is what I imagined the thumbs-up/down on a profile would do. If a person with lots of karma gives you a thumbs-up, you get more karma than if someone with little karma gives you a thumbs-up. However, lots of low level users giving you a thumbs-up would equate with a single mid-level person.

However, I don't think it was implemented, and the profile thumbs up/down were removed.

[Which reminds me, if there's more midgard work to be done, karma calculations need a re-architect so that everything isn't scanned every update, so that a) there won't be sudden shifts if one source is down; b) updates are more timely and c) karma decay can be implemented]
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 

The Following User Says Thank You to Jaffa For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 10:44.