On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams <cmadams@xxxxxxxxxx> wrote: > Great - let's take something that people are using, remove that > functionality, and not announce it! > > This is not cool; it represents one of my biggest frustrations with a > bunch of the "new and improved" ways of doing things. You track down > how to do something, it works for a few releases, and then it doesn't > anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that "power users" can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. More on the subject— in this brave new polkit JS world, when an administrator is considering upgrading their Fedora (or even some packages), what tools will they have to validate that their local JS actually works at all much less produces the desired behavior? I don't see any tools or documentation to facilitate that. It seems to me that adding a bunch of unsound programmatic configuration which can't reasonably be used by the end users due the overhead of keeping up regular fedora churn, especially absent good validation tools, is not a productive change relative to just baking in the additional logic and exposing it via basic configuration switches. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
