compiz team mailing list archive

["Sam \"SmSpillaz\" Spilsbury" <smspillaz@xxxxxxxxx>]

On Tue, Jun 7, 2011 at 7:17 AM, Omer P. <767095@xxxxxxxxxxxxxxxxxx> 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     : compiz@xxxxxxxxxxxxxxxxxxx
> 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 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