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 -- Sebastian Krzyszkowiak dos _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
