Thank you for the enlightenment, Sebastian.
But when I speak of critical bugs I'm obviously not talking about this
little regression. I just picked up on another small discussion to prove
an ongoing point.
I'd prefer to see serious bugs like the SDcard freeze problem being
solved before anyone goes on refactoring python daemons into vala daemons.
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.
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'll shut up now. I'm becoming too negative in this thread.
Sebastian Krzyszkowiak wrote:
On Fri, Apr 30, 2010 at 14:52, Vasco Nevoa <[email protected]> wrote:
Sebastian Krzyszkowiak wrote:
Please try to avoid judging without knowing anything about what you're
talking. With odeviced IT WORKED as you wanted - settings was stored
and they were easly changable by SHR Settings UI. It changed when
migrating from odeviced to fsodeviced, which is regression in FSO
stack, not "usability decision"...
The migration from odeviced to fsodeviced is in itself a usability decision.
Why else would you want a new deviced if not for flexibility and feature
addition?
I completely understand the value of the FSO roadmap, and I sincerely hope
it does get implemented, but I also think that the critical bugs in the
system should have higher priority than ANY new features or refactoring.
The thing is - it's not critical bug. You can still tweak values, it's
just little harder.
Why else would you want a new deviced if not for flexibility and feature
addition?
I don't think so, there are mostly feature regressions with new
cornucopia daemons (for example latest ogsmd->fsogsmd migration), but
we decided to do that anyway in order to improve overall stability and
fix bugs, which could be hard to fix with old, python stack.
Of course, as with every big migration, there will be problems at
beginning, but that's why we are doing that - to fix these problems.
You're really shouting about minor, non-existent problem, and don't
forget that you're also part of our community, so you all can send
patches to us if there's something you don't like :P
_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user
