On Tue, Jun 7, 2011 at 7:17 AM, Omer P. <767...@bugs.launchpad.net> wrote: > I appreciate your work, Sam. > > [rant] > > But I think there's a separate lesson to be learned here: When such a > major overhaul as was done to compiz is undertaken, making it impossible > for users to use the previous version (as was the case here, where natty > users *could not* go back to 0.8.6, until Guiodic made his wonderful > PPA) is just bad practice.
Non-LTS releases are places where we land software that is coming out of upstreams and polish it for our users. Of course, I understand that there is a bar of stability that we aim to achieve, and of course, I understand that we've fallen short (way short, and this is my fault as the maintainer of compiz) of that bar, however that's not to say that progress must be made, hard decisions have to be taken etc. I'm not going to try to provide justification for why things were done the way they were during the N cycle. It was difficult for everyone, most notably because the entire stack was completely rewritten from the ground up. Providing packages for users to use during the 'classic' session of the 0.8.x release series of compiz is something that we could have done. However, I believe that the burden here far outweighs the benefits of switching to 0.9.x completely. Shipping packages for 0.8.x would mean that we'd have to distro-patch all of compiz 0.9 or 0.8 to provide separate binary names in the packages. It also breaks upgrade paths when users are upgrading and they need to maintain two sets of plugins for 0.8 and 0.9. Finally, when we want to remove compiz 0.8 from the system, there's no sane way in apt that we could replace it without introducing artificial conflicts. Additionally, I think that shipping the 0.8.x series would have had far more wide reaching effects than just having to put in the effort to maintain an outdated stack. First of all, like we saw with distributions that shipped KDE4 and KDE3 simultaneously, KDE4 was the victim of an immediate backlash and everyone reverted back to KDE3. The result of this is that KDE4 got hardly any end user testing and this seriously stifled the development of KDE, since the developers didn't know what users priorities were in the bug reports. Now even today, only now are people starting to get used to KDE again. But the fact that users were given an option to "opt-out" of that testing means that the KDE project was seriously crippled in being able to determine its priorities. I don't think that compiz 0.9.x would have matured so quickly in the same way that it did during the N cycle if we didn't receive the same amount of testing that we did. Being able to sift through all the bug reports showed us the actual usage patterns of normal users and allows the developers to address those problems. For example, I don't use any Qt apps which use the system tray (not a fan of skype) and I surefire would not have noticed this bug (which is a race condition in the way reparenting works in compiz) had users not tested it. The moral of the story here is that if we provide users the option to run away from the problems, then the discourse turns from "solutions are created by the developers who fix the problems" to "solutions are created by users who work around the problems". I believe that the latter mindset is an incredibly dangerous one to have, since it encourages developers to stay in "maintenance mode" on old codebases, which eventually leads to more stagnant, rigid code which cannot be improved easily, which leads to increased fragility and increased burnout over time as developers are constrained in creating new solutions. Of course, I also recognize that "forcing" ordinary users to be the test ground for new software is also not a good mindset to have, since it increases complacency in users for what perfection we really should be striving for. As such, I believe we require a balance, and the solution to that problem is to invite more people in to learn the code, to fix it and to take ownership of it and give it a direction rather than either being fearful to make big leaps because we give users the option to run away or dropping bombs on users because we can. > > There are numerous other problems with the current version of compiz, > numerous other reasons to want to stay at 0.8.6 for now (for example, > the newer version crashes every window decorator except the unity- > window-decorator, such as emerald, etc.) -- this is not a knock on > compiz or its developers, of course; no software is free of bugs, and > early in the lifecycle of every new major overhaul, there will be its > share of problems. Not only that, but I imagine some of the > compatibility issues (e.g. emerald) are just as likely to be bugs in the > interfacing modules, rather than bugs in compiz. But the fact that > someone had to hack a solution to enable users to downgrade is just poor > usability. > > [/rant] > > -- > You received this bug notification because you are a member of compiz > packagers, which is subscribed to compiz in Ubuntu. > https://bugs.launchpad.net/bugs/767095 > > Title: > 1 pixel icons in notification-area-applet when compiz is the windows > manager > > _______________________________________________ > Mailing list: https://launchpad.net/~compiz > Post to : com...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~compiz > More help : https://help.launchpad.net/ListHelp > -- Sam Spilsbury -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/767095 Title: 1 pixel icons in notification-area-applet when compiz is the windows manager -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
