On 2010-04-30, Vasco Nevoa wrote: > I'd prefer to see serious bugs like the SDcard freeze problem being > solved before anyone goes on refactoring python daemons into vala daemons.
You forget that we are different people with different skills and interest. Not all of us are kernel hackers that can debug SD card corruption. So should we all twiddle our thumbs until someone has found out the cause and fixed it? :-) Also, I have never experienced an SD card hang, so why should I want to wait until things progress? It has taken way too long until I got my FR to make phonecalls reliably anyway... > As I said, I understand why this migration is being done and I support > it - but it was too soon to do it. There are still fundamental problems > to solve before the system gets a new coat of polish. Being able to make phone calls is a bit more than polish, and with the old python frameworkd people had already hung up again until I succeeded in unlocking the thing, picking up the phone and getting a connection established. So in terms of basic functionality, I am much happier now that I was a year ago. As for those "decisions" yes, I also don't agree with many of them. But those who actually do the work get to say what interests them most, and if the main opimd developer has no interest in SIM cards we can hardly blame him for not working full time on that feature. If people are missing something, they can improve it, as e.g. Heinervdm has done with his SIM manager that allows for nice copying of contacts from the SIM card to the sqlite.db. I would say you are expecting something too professional from a bunch of spare time hackers. Everything you say makes sense, but there is no way of forcing someting on individuals who do something voluntarily if they have no interest in it. That having said, you are using shr-unstable, right? shr-t is still using python-based ogsmd and will try to bump things much more selectively and infrequent than shr-u (although I don't always succeed in the selective and well-test part of the picture). > And when I said "usability decisions" I wasn't thinking much about this > little thing, I was more thinking about how the SIM support just > disappeared with opimd and the user's laments are ignored with a "this > is the best way to do it" comment. > SIM backend support should have been at least a public poll on the list. I agree that I would have loved to keep it, but what if the guy developing it has simply no interest in SIM cards? What if the poll votes in favor of SIM cards (as I am sure it would have done). Should we have put a knife at his throat and force him to code up things he has no interest in? :-) No offense taken, and no harm done, I hope. I agree that there are many things amiss, but then never forget: THis is not openmoko.inc and nobody here is paid to work for increased "customer satisfaction". People work to solve their own itches and whatnot.... spaetz
pgp06KoxsSwUy.pgp
Description: PGP signature
_______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
