Comment 4 for bug 721572

Cal: thank you for reporting that the bug, it took your time, and that is appreciated. Reporting bugs allows them to be documented. Documented bugs allows them to be researched and fixed.

The same requirement to locate, document and fix bugs applies equally, whether you're using GNOME with GNOME2 Panel, GNOME with GNOME3 Shell, GNOME with XFCE, GNOME with Unity (-compiz) shell, GNOME with Unity-2D shell, GNOME with Ubuntu classic desktop, or GNOME with …

Everyday, the same core bugs exist across distributions, and just like them, the same core bugs are also there across across Shells across distributions. The bugs exist, and they just manifest themselves differently depending on the environment. More testers, more diverse codepaths, more shells, more use-cases: these all help to pin-point the bugs that are in there. In the example I gave earlier on the Sounder mailing list, the bug had *always* been there, and wasn't even in, or caused by Unity. Instead, it was the in-depth large-scale testing of Unity that brought it to the front and ensured that a bug finally got the attention it deserved:

  https://lists.ubuntu.com/archives/sounder/2011-April/016120.html (talking about bug #175874)

To makes things more comfortable, I have unduped bug #733766, twiddled the status around to "Needs Info" (it's unclear how to reproduce it at the moment), and *with the status twiddled* I've remarked it as a duplicate of this bug. The original status under a duplicate does not matter in this case, but I appreciate how it could be seen as dismissive. It has not been dismissed, but has proactively been marked as an intimate associate of this bug, which is scheduled to be worked on (admitted, set at Low at the moment since it's a event-based rendering glitch and doesn't appear to cause any data-loss). If you can highlight how this might cause wider issues, we can perhaps both work to bump up the priority.

In the case of bug #733766 (your report), bug #747982 (the other dup) and this bug report: there's clearly a commonality in the logic failure: something that is failing in knowing when to poke dbus-menu with the updated value for the disabled entry date entry in the calendar menu. The various manifestations of "at midnight", or "missed during suspend" or "randomly on other undefined but unclear occasions" (to paraphrase your specific report) are clearly *not isolated* and are ultimately going to get investigated and solved at the same time.

I'm more than happy to further tweak the summary line of this bug report if you can suggest a title that would be more appropriate, the title is there to aid and help /other users and developers/ to find /this bug/ themselves when searching.

Specifically on "back to Gnome": regardless of where a user downloads their GNOME environment from, there *will* be an enforced change in default graphical shell in the short/medium-term. GNOME + GNOME3 Shell is arguably a big jump for people who have not seen it before, and GNOME + Unity is another jump. One might be a shorter jump than the other for any particular group of people depending on their past experiences. Neither new shell option is perfect and both need to gain from help with bug-fixing. Indeed, the high-level process outlined in the first paragraph is going to be the same.

As a comparision; five years ago ACPI caused no end of problems, and "acpi=off" had to be the most frequently-touted work-around to regain/keep the status quo. The *ultimate solution* was not to simply ignore the issue of broken ACPI, but instead to focus that energy on fixing it. Fixing it head-on and with the acceptance the end-goal was worthwhile, and /would/ fix it _properly_ for a everyone else at the same time. While a quick fix for one person is satisfying for a moment, it's even more satisfying to solve a bug for millions of other people at the same time.