Bugzilla Bug 30264

The GNOME desktop switcher has been misbehaving since I upgraded to gnome 2.4 -
on both my desktop and notebook.  Specifically, what's happening is that the
workspace is "moved" - so it appears that all the windows on the desktop move
around when switching between desktops using the pager.  For more details, it's
covered in these bugs on bugzilla.gnome.org:

http://bugzilla.gnome.org/show_bug.cgi?id=122512
http://bugzilla.gnome.org/show_bug.cgi?id=122205
http://bugzilla.gnome.org/show_bug.cgi?id=122086

The latter has a patch for libwnck which, to my understanding, fixes the
problem by not moving the viewable desktop area if your desktop size is fixed
(which is the correct behaviour).  The patch applies cleanly to
libwnck-2.4.0.1, and I can verify that applying it fixes the problem.

Created an attachment (id=18686) [edit]
Patch for libwnck to correct switcher behaviour

Created an attachment (id=18687) [edit]
Updated libwnck-2.4.0.1-r1 ebuild that applies patch

*** Bug 30641 has been marked as a duplicate of this bug. ***

applied to libwnck-2.4.0.1 in portage, thanks for your report + gnome bugzilla
links.

*** Bug 30934 has been marked as a duplicate of this bug. ***

Can someone explain to me why this wasn't bumped to -r1?  Since it now installs
something DIFFERENT (i.e. fixed) than the original 2.4.0.1, it should have
been bumped so that people get the updated ebuild.  I could understand it
if 2.4.0.1 hadn't been installable, but if this isn't a case in point for
a -r bump, I can't see what is - and duplicates (e.g. bug 30934) are still
occuring because it wasn't bumped.

To backup what I said in comment 6, from the Gentoo Linux Development Policy
page, at http://www.gentoo.org/doc/en/policy.xml:

============

Versioning and revision bumps 

Package revision numbers should be incremented by Gentoo Linux developers
when the ebuild has changed to the point where users would want to upgrade.
Typically, this is the case when fixes are made to an ebuild that affect
the resultant installed files, but the ebuild uses the same source tarball
as the previous release.

============

as with all policy, the guidelines are just that, each situation needs to
be interpreted by them. it's always important to consider that a revision
will cause all users, those seeing the bug, and those not, to rebuild the
package (if you were going to requote 'when the ebuild has changed to the
point where users would want to upgrade'). in the light that this bug was
caught within a few days of gnome going stable, and that it seems few people
are actually seeing this bug (few in comparison to the other major gnome
2.4 questions/bugs we got), it was deemed unnecessary for a revision bump.

I realize that some packages have revisions bumped far too much, for trivial
things - in some cases, I've seen a ebuild bumped because someone cleaned
up an ebuild without actually changing anything of the final program installed.
 However, in this case, anyone who has installed libwnck before it was silently
updated, now have a broken gnome desktop switcher - and you're trying to
say those users would NOT want to upgrade?  In the light of the fact that
duplicates bugs have been filed SINCE this was fixed, I ask you to reconsider
bumping this.

>>> as with all policy, the guidelines are just that, each situation needs
to
be interpreted by them. <<<

Very true.  What I don't understand is how package A, which was released
broken, should be fixed for those people who install it after a certain date,
but without hunting down this bug report, people who installed it BEFORE
that date will not be able to resolve the issue.

This guideline is particularly important as Gentoo should strive for any
specific version of a package being the same across all systems (so long
as compiler settings/use flags/etc. are the same).  Without some consistency,
saying "I have package-x.y.z installed; could it be causing the problem?"
does not allow someone to respond "I have the same version installed, without
any problems" - which they should be able to do, in order to enable users
to help one another.

To quote further from the guidelines:

=============
If you make an internal, stylistic change to the ebuild that does not change
any of the installed files, then there is no need to bump the revision number.
Likewise, if you fix a compilation problem in the ebuild that was affecting
some users, there is no need to bump the revision number, since those for
whom it worked perfectly would see no benefit in installing a new revision,
and those who experienced the problem do not have the package installed (since
compilation failed) and thus have no need for the new revision number to
force an upgrade.
=============

The change was neither stylistic nor a compilation fix - so there doesn't
seem to be much basis for your creative interpretation of the developer guidelines.
 Had libwnck been ~x86, I could understand the argument for not bumping the
revision, but this was out in stable x86 for 3 full days, and in ~x86 for
nearly a month - how many users do you suppose installed it and have no idea
there is a fix available for this behaviour?  All of those users don't want
bugs to be fixed?

>>> it's always important to consider that a revision will cause all users,
those seeing the bug, and those not, to rebuild the package <<<

libwnck is a pretty small package; recompiling is not as significant as compiling
qt or openoffice, for instance.  And I am sure that there are users out there
with this installed who would like it fixed.

Jason is correct. It is pretty important to bump the revision when the
installation
is changed in any significant way, especially bugfixes.

Obz, can you offer an explanation for why it would be harmful to bump the
revision? Certianly, people will have to recompile, but this is not a huge
package.

nor is it a major bug, if we had to bump for every little fix people would
have to recompile considerable more. I don't understand why this gets so
much attention and someone writes up such a big story as to why this is a
mistake complete with a days worth of research on the subject including both
ethical and functional complaints.

I see this happen with seriously larger ebuilds and more important fixes
on a bigger scale and nobody makes a big fuzz there. Go find some other windmills.

In short, the idea is that very few people of the considerable amount that
use this package will encounter this bug (to my knowledge it will not happen
on a default install), so it's not worth making all of them download and
upgrade in my opinion. I think this all was quite clear from Obz initial
comment.

It is a potentially important bugfix on a package with a ~300k tarball. There
is no disadvantage to bumping the revision.

Policy is that revision bumps are necessary if the material actually getting
installed changes. If you don't agree with that policy, perhaps we should
discuss that policy on -dev -- bugzilla's not really the right place for
it.

In any case, Obz has fixed it and it's a dead issue.

In reply to comment 11, my point here was not so much about this package
specifically, but about the tendency of some developers to make significant
fixes without bumping the revision - in this case, the bug _was_ fairly significant
as it affected everyone and anyone who uses the gnome desktop switcher with
the unpatched libwnck.  If my "days worth" of research (which consisted of
a 5 minute look at the developer guidelines, and 15 minutes to write it up)
helped Gentoo follow its own guidelines, then as a user of Gentoo, it seems
worth it to me.  You may not agree, and I leave you to your opinion.

In any event, both issues here are now fixed.

> in this case, the bug _was_ fairly significant
> as it affected everyone and anyone who uses the 
> gnome desktop switcher with the unpatched libwnck.

that's not entirely correct. and please, dont close bugs pre-emptively, i
was leaving this open on purpose so i could remind myself to mark the new
2.4.0.1-r1 stable on x86 (which is happening today on advice from avenj).
in any case, bug closed.